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I.  INTRODUCTION 

A.  PROBLEM  STATEMENT 

The  recently  completed  integrated  project  by  the  Systems  Engineering  and 
Analysis  Cohort  15  (herein  referred  to  as  Project  SEA- 15)  [1]  in  June  2009  has 
recommended  an  alternative  force  structure  for  operating  in  a  maritime  environment 
during  the  initial  phase  of  military  operations  known  as  Phase  Zero.  The  Phase  Zero 
operation  is  comprised  of  three  primary  missions:  anti-smuggling,  civil  support,  and 
information  sharing.  The  force’s  airlift  capability  was  also  found  to  be  a  critical  factor  in 
the  accomplishment  of  the  civil  support  mission.  Two  variants  to  the  force  structure  were 
proposed;  one  based  on  current  platforms  only,  and  the  other  with  the  inclusion  of  future 
platforms  that  are  deployable  by  2020,  using  total  procurement  and  operating  costs  of 
$1.5B  (FY08  constant  dollars)  per  annum. 

As  part  of  the  solution,  the  force  structure  required  for  airlift  operation  support 
was  determined  by  using  a  mix  of  mathematical  and  linear  optimization  modeling  to 
ensure  that  all  critical  requirements  defined  for  the  mission  scenarios  could  be  satisfied  at 
the  lowest  cost.  The  modeling  was  done  using  high-level  and  static  performance 
parameters  that  did  not  take  into  consideration  the  tactical  operation  factors  in  a  dynamic 
operating  environment.  While  the  abstraction  may  be  adequate  to  support  front-end 
strategic  level  planning,  it  does  not  have  the  resolution  to  support  a  proper  performance 
analysis  for  the  recommended  force  structure  at  the  operation/tactical  level.  For  example, 
the  optimization  model  has  assumed  unlimited  landing  spots  and  a  logistics  crew  that  can 
support  the  concurrent  loading  of  airlift  platforms  using  a  fixed  loading  time.  The 
missing  details  are  particularly  important  in  this  case,  as  the  airlift  operations  are  meant 
to  support  disaster  relief  missions  characterized  by  short  notice,  high-load  demands  with 
a  compressed  delivery  schedule,  where  the  task  force’s  real-time  throughput  performance 
matters. 
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It  is,  therefore,  necessary  to  provide  a  higher  resolution  model  to  augment  the 
analysis  work  that  has  already  been  performed  under  the  Project  SEA- 15  so  that  a  more 
complete  solution  can  be  made  available  to  any  stakeholders  who  want  to  take  the  project 
to  the  next  level. 

B.  OBJECTIVES  AND  SCOPE 

The  main  goal  for  the  thesis  work  is  to  develop  a  dynamic  model  using  the 
Discrete  Event  Simulation  (DES)  that  can  be  used  to  analyze  the  airlift  operation 
performance  of  the  naval  force  structure  recommended  by  Project  SEA- 15  at  the 
operational/tactical  level.  A  data-driven  model  will  be  developed  to  mimic  the  airlift 
operation  process  with  the  key  factors  abstracted  as  user-definable  parameters  to  facilitate 
the  analysis  work  in  different  settings. 

With  the  appropriate  input  data,  the  model  output  can  be  used  to  validate  the 
performance  of  recommended  force  structures  under  different  scenario  requirements  and 
support  sensitivity  analysis  to  identify  key  areas  that  may  limit  or  improve  the  force 
structure  capabilities  and  effectiveness  in  a  different  operating  environment.  The  model 
will  help  stakeholders  answer  the  following  questions: 


•  Is  the  proposed  force  structure  optimized  or  feasible  as  per  the  high-level 
static  analysis  suggested  it  might  be? 

•  What  are  the  operating  profiles  for  the  proposed  force  structure,  e.g.,  the 
duration  to  complete  a  mission,  the  number  and  the  sequence  of  the  sorties 
flown,  etc.? 

•  What  are  the  lower  level  performance  measures  for  the  proposed  force 
structures  and  how  well  are  they  being  met  under  the  different  mission 
demands,  including  operational  availability,  utilization  rate,  etc.? 

•  How  will  the  proposed  force  structure  capabilities  and  effectiveness  be 
affected  by  the  operation  and  logistics  support  constraints?  For  example. 
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what  is  the  number  of  concurrent  sorties  that  can  be  supported  and  the 
turnaround  time  between  sorties  under  the  possible  constraints  of  limited 
landing/loading  spots  and  logistics  crew  support? 

•  What  are  the  force  structure’s  capabilities  and  limitations  beyond  the 
current  designed  mission  envelope? 

•  Can  the  proposed  force  structure  be  modified  to  achieve  better  mission 
effectiveness  without  impacting  the  other  Phase  Zero  operation  support? 
If  so,  what  are  the  possible  alternative  structures  and  associated  strengths/ 
weaknesses? 

C.  PROJECT  SEA-15  OVERVIEW  [1] 

1.  Background 

Project  SEA-15  was  conducted  under  NPS’  System  Engineering  Analysis 
curriculum  as  a  capstone  project  for  the  students  to  combine  their  learning,  and  as  a  team, 
solve  a  real  world  problem.  Thirty-three  students  from  the  United  States  (U.S.),  Israel 
and  Singapore  participated  in  the  project  over  a  six-month  period.  The  tasking  given  to 
this  cohort  came  from  the  Warfare  Integration/Senior  National  Representative  (OPNAV 
N8F),  which  was  to  devise  a  maritime  force  for  Phase  Zero  mission  deployable  by  year 
2020.  Specifically: 

Design  a  system  of  systems  to  employ  a  regional  Maritime  Theater 
Security  Force  to  conduct  all  maritime  missions  associated  with  Phase 
Zero  operations.  Consider  current  fleet  structure  and  funded  programs  as 
the  baseline  system  of  systems  to  execute  security  and  shaping  missions  in 
developing  these  concept  of  operations,  then  develop  alternative  fleet 
architectures  for  platforms,  manning,  command  and  control, 
communication,  logistics  and  operational  procedures  to  evaluate  against 
the  current  program.  A  complete  redesign  of  a  naval  force  capable  of 
executing  phase  0  operations,  employable  by  2020,  and  using  total 
procurement  and  operating  costs  of  $1.5B  (FY08  constant  dollars)  per 
annum,  should  be  one  of  the  alternatives. 
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2. 


General  Work 


The  first  thing  that  the  team  did  was  to  develop  a  mission  statement  for  the 
required  maritime  force.  After  much  research  on  the  various  definitions  for  the  term 
Phase  Zero,  and  their  relevance  to  the  world’s  current  landscape,  the  team  has  decided  on 
the  following: 

A  Phase  Zero  force  will  work  closely  with  multinational,  interagency  and  other 

partners  to  maintain  or  enhance  stability,  prevent  or  mitigate  crises  and  set  the 

conditions  for  access  and  responsive  crisis  intervention. 

Based  on  the  mission  statement,  the  team  has  identified  the  following  13  essential 
missions  that  they  believe  will  collectively  contribute  to  the  overall  accomplishment  of 
the  Phase  Zero  force: 

•  Civil  Support 

•  Train  the  local  defense  force 

•  Equip  the  local  defense  force 

•  Build  relations  with  foreign  nations 

•  Restore  critical  infrastructure 

•  Anti-smuggling  operations 

•  Anti-terrorism  operations 

•  Anti-illegal  fishing  operations 

•  Force  protection  against  threats 

•  Anti-piracy  operations 

•  Information  sharing 

•  Freedom  of  navigation 

•  Non-combatant  evacuation  operations 
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Given  that  there  were  similarities  in  terms  of  how  these  missions  would  be 
executed,  and  the  types  and  characteristics  of  platforms  involved,  the  team  was  able  to 
consolidate  the  missions  into  three  key  ones,  namely  information  sharing,  anti-smuggling 
and  civil  support,  using  a  multidimensional  scaling  technique.  Figure  1  is  the  generated 
perceptual  map  illustrating  how  the  various  missions  were  perceived  to  be  similar  to  one 
another.  They  are  represented  by  their  physical  proximities  on  the  map,  based  on 
surveyed  inputs  from  individuals  across  NFS,  including  members  from  Operations 
Research  and  Systems  Engineering  Departments,  the  Naval  War  College  and  subgroup 
leads  within  the  project  team. 


-1 
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«elfDef 


C^ml:  Provide  Civil  Supppoit 
lufra:  Restore  Critical 
Lifi’astnictiire 
Sliliifel:  Share  intelligence 
with  Paitiiers 

EqiiipLcl:  Support  Equipping 
of  Local  Defense  Forces 
TraiJiLcl:  Train  Local 
Defense  Forces 
BuilclRel:  Build  Relations 
with  Local  Govenmients 
Smug:  Reduce  Smuggling 
2  ATO:  Conduct  Anti- teiTorism 
Operations 

Piracy:  Combat  Piracy 
Fish:  Prevent  Illegal  Fishing 
FON:  Enforce  Freedom  of 
Navigation 

SelfDef:  Provide  for  Force 
Self  Defense 
NFO:  Conduct  Non- 
combatant  Evacuation 


Figure  1 .  Phase  Zero  Perception  Map  (from  [1]) 


Based  on  these  three  primary  missions,  the  formulation  of  the  force  structure  was 
carried  out  in  the  following  six  phases: 

•  Consolidate  the  background  information  required  for  modeling  the  force 
structure,  covering  studies  on  the  threat  environments,  platform 
availability  and  capabilities,  etc.. 
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•  develop  mission  requirements  and  scenarios  to  allow  for  further  analysis  in 
identifying  the  critical  attributes  that  will  impact  the  accomplishment  of 
these  missions, 

•  perform  gap  analysis  on  current  forces  used  for  Phase  Zero  type  missions 
and  develop  lessons  learned, 

•  develop  initial  force  structures  that  could  meet  the  mission  requirements  at 
the  various  levels  defined.  For  each  level,  two  force  structures  are 
required,  one  based  on  current  platforms  in  the  U.S.  inventory  only  and  the 
other  with  future  platforms  deployable  before  2020. 

•  apply  optimization  to  determine  the  lowest  cost  configuration  and  fine- 
tune  the  results  as  required  to  produce  the  final  force  structures,  and 

•  conduct  a  logistics  requirement  study  to  work  out  the  overall  capabilities 
and  costs  for  each  force  structure  and  with  that,  recommend  the  one  that  is 
deemed  most  suited  for  the  Phase  Zero  missions. 

Two  mission  scenarios  were  created  to  simulate  the  Civil  Support  and  Anti¬ 
smuggling  missions  in  the  Latin  American  area  of  responsibility.  Latin  America  was 
chosen  because  there  was  a  rich  archive  detailing  past  Phase  Zero  type  missions 
conducted  there  that  would  provide  the  necessary  background  information  for  the  team  to 
construct  the  mission  scenarios.  The  other  reason  was  that  Latin  America  was  one  of  the 
key  areas  where  drug  trafficking  and  humanitarian  crises  prevailed. 

The  Anti-smuggling  scenario  was  constructed  using  a  barrier  patrol  concept  to 
simulate  an  effort  to  quell  drug  smuggling  along  the  western  coast  of  Mexico.  The 
aviation  elements  and  the  size  and  speed  of  intercept  vessels  were  found  to  be  the  most 
important  force  attributes  in  identifying  and  interdicting  drug  smugglers  in  that  area.  The 
Civil  Support  scenario  was  modeled  after  the  need  to  support  the  Latin  American 
populace  following  a  natural  disaster  based  on  three  different  levels  of  severity,  and  it 
was  found  that  the  forces’  shipboard  cargo  capacity  and  its  airlift  capacity  were  most 
crucial  in  accomplishing  the  missions.  Information  Sharing  requirements  were  studied  as 
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part  of  the  two  scenarios  based  on  how  it  could  be  employed  to  support  the  two 
operations,  and  in  both  cases,  a  reliable  and  fast  means  for  sharing  information  was  found 
to  be  a  force  multiplier  to  the  missions. 

Six  force  structures  were  generated  and  after  going  through  the  optimization,  fine- 
tuning  and  logistics  considerations,  the  one  devised  for  the  high-severity  scenario  with 
the  inclusion  of  future  platforms  was  eventually  recommended  as  the  force  structure  most 
suited  for  the  Phase  Zero  missions.  The  recommended  force  structure  is  summarized  in 
Table  1  and  its  amortized  annual  cost  is  estimated  at  $360M,  which  allows  four  such  task 
forces  to  be  deployed  at  different  areas  of  responsibility  (AOR)  given  the  $1.5B  annual 
budget. 


S/N 

Ship 

Organic  Assets 

1. 

One  JMSDF  DDK  class 
destroyer 

Seven  CH-53K  Sea  Stallion  helicopters  and  six  RQ-8 
Firescout  UAVs 

2. 

One  LPD-17  San  Antonio 
class  amphibious  assault 
support  vessel 

Two  SH-60S  Seahawk  helicopters,  six  RQ-8  UAVs 
and  two  M-80  Stiletto 

3. 

One  Joint  High  Speed 
Vessel  (JHSV) 

Nil 

4. 

One  Visby  class  corvette 

Six  RQ-8  Firescout  UAVs 

Table  1 .  Recommended  Force  Structure  For  Phase  Zero  Mission 


The  SH-60  version  was  not  explicitly  stated  in  the  report  [1]  under  the 
recommendation  section  but  based  on  the  quoted  performance  specifications  and  the 
references  made  in  other  sections  of  that  report,  it  can  be  inferred  to  be  SH-60S  (or  the 
equivalent  MH-60s). 

The  specific  capabilities  for  the  platforms  in  the  recommended  force  structure  are 
provided  in  the  Appendix  A. 
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D.  RELATED  WORK 


1.  Related  Work  in  Airlift  Operation  Modeling 

There  were  studies  found  involving  the  modeling  of  airlift  operations  but 
performed  in  a  dissimilar  context  or  using  different  tools/approaches  with  respect  to  this 
thesis  work.  They  are  summarized  below: 

•  Curtin  [2]  has  analyzed  the  Sea  Based  Logistics  (SBL)  concept  involving 
inter-ship  and  intra-ship  movement  of  material  in  his  thesis  work.  A  DES- 
based  software  package  known  as  ARENA  was  used  to  simulate  the  inter¬ 
ship  process  of  transferring  pallets  of  load  from  a  supply  ship  to  a  LHD 
class  amphibious  ship  using  vertical  replenishment  (VETREP)  with  CH-46 
helicopters  followed  by  the  intra-ship  movements  of  the  pallets  from  the 
landing  spots  to  the  storage  area  using  forklifts.  The  analysis  focused  on 
the  operational  impact  due  to  the  number  and  lift  capacity  of  the  aircraft 
used.  The  study  concluded  that  increasing  the  aircraft  lift  capacity  will 
significantly  reduce  the  total  cycle  time,  whereas  having  more  aircraft  only 
marginally  reduced  the  cycle  time. 

•  Kang,  Doerr,  Bryan  and  Ameyugo  [3]  have  looked  into  another  aspect  of 
the  SBL  concept,  i.e.,  to  provide  replenishment  and  logistics  support  for  a 
deployed  force  ashore  through  direct  Ship-To-Objective  Maneuver 
(STOM).  A  DES  model  was  developed  to  assess  the  STOM  operations 
using  an  LHD-class  amphibious  ship  as  a  sea  base  supported  by  12  MV-22 
Osprey  airlift  platforms  to  transfer  pallets  (of  load),  bladders  (of  water), 
fuel  and  personnel  ashore  over  a  15-day  mission.  The  simulation  results 
indicated  that  the  number  and  reliability  of  the  aircraft,  as  well  as  the 
sustainment  requirements  for  the  force  ashore,  were  the  critical  factors  for 
mission  success  based  on  those  scenarios  set  up  for  the  study. 

•  Granger,  Krishnamurthy  and  Robinson  [4],  on  the  other  hand,  have 
conducted  a  macro  level  analysis  on  a  global  airlift  network  across  wider 
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geographical  locations  involving  intermediate  airfields.  Two  stochastic 
models  employing  different  techniques  were  developed  to  support  the 
analysis  work,  and  at  same  time,  to  compare  the  capabilities  of  the 
techniques  used  for  such  work.  The  first  model  was  simulation  based, 
developed  using  a  commercial  software  package  known  as  ProModel, 
while  the  second  model  employed  a  network  approximation  method  and 
was  built  using  another  commercial  software  package  known  as  MPX. 
The  models  mimicked  the  transfer  of  cargo  from  an  Aerial  Port  of 
Embarkation  (APOE)  to  the  Aerial  Port  of  Debarkation  (APOD)  with  three 
intermediate  airfield  options  as  depicted  in  Figure  2.  Based  on  the 
experiment  setting,  the  analysis  has  shown  that  increasing  the  variability  of 
ground  times  would  correspondingly  increase  the  waiting  time  at  airfields 
and  that  fleet  size  has  an  opposing  impact  on  airlift  operation  completion 
times  and  delivery  flow  times.  The  study  has  also  demonstrated  that  the 
approximation  method  based  model  was  much  more  efficient  than  the 
simulation  model,  utilizing  only  2%  of  the  time  taken  by  the  latter  model 
to  complete  analysis,  but  at  the  expense  of  potential  loss  in  accuracy.  The 
authors  further  suggested  that  the  combination  of  the  two  techniques 
would  likely  yield  better  performance  than  using  either  of  them 
standalone,  and  warrants  future  work. 
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2.  Related  Work  in  DES 

DES  is  a  modeling  technique  widely  used  to  simulate  systems  where  the 
phenomena  of  interest  changes  value  or  state  at  discrete  points  in  time,  rather  than 
continuously  across  the  time  horizon  [5].  As  an  alternative  to  the  traditional  time¬ 
stepping  simulation,  DES  provides  a  much  more  efficient  means  of  modeling  such 
systems  as  it  skips  through  all  dormant  moments  in  time  where  there  are  no  occurrences 
that  would  matter  to  the  simulation  outcome.  DES  is  particularly  useful  in  supporting 
analysis  work  with  its  inherent  abilities  to  compress/expand  time,  control  sources  of 
variation,  restore  system  state,  stop  anytime  for  review  and  facilitate  replications  [2],  The 
following  are  examples  of  some  recent  studies  done  using  DES  to  support  the  analysis 
work: 

•  Ouerghi  [6]  has  employed  DES  together  with  X3D  visualization  in  his 
thesis  work  to  look  into  problems  related  to  ground  traffic  incursions  and 
provide  insights  into  possible  cases  that  could  result  in  potential  accidents. 
Specifically,  models  mimicking  aircraft  arrivals  and  departures  in  an 
airport  were  developed  to  analyze  the  impact  as  the  aircraft  try  to  gain 
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access  to  the  taxiway  and  runway  at  the  same  time.  The  findings 
concluded  that  the  approach  has  demonstrated  “a  proof-of-concept 
capability  worthy  of  future  work.” 

•  Wong  and  Ong  [7]  have  demonstrated  the  feasibility  of  using  DBS  and  the 
multi-agent  system  (MAS)  to  validate  an  air  defense  plan  in  their  thesis 
work.  In  their  study,  MAS  was  used  to  generate  an  aggressor’s  air  strike 
plans  based  on  tactics  described  in  air  strike  doctrines  with  DBS  models 
constructed  to  simulate  the  air  defense  assets  and  their  interaction  with  the 
aggressor’s  fighters.  The  developed  system  has  also  proven  useful  for  air 
defense  planners  for  looking  into  the  dynamics  of  the  causal  effects 
between  their  air  defense  plans  against  the  various  possible  strike  plans. 

•  Alexander  [8]  has  explored  DBS  in  the  manufacturing  process  setting  to 
analyze  cycle  time  and  timing  interactions  between  process  phases  as  an 
alternative  to  the  conventional  approach  of  using  static  methods  to  lay  out 
the  batch  sequencing  and  scheduling  with  tools  like  Microsoft  Project  or 
Microsoft  Bxcel.  A  sample  DBS  model  was  developed  to  assess  the  water- 
for- injection  (WFI)  system  usage  under  some  proposed  batch  sequence 
improvements,  which  will  drive  up  its  demand.  The  simulation  result  has 
surfaced  the  critical  factor  for  achieving  the  most  desirable  WFI  system 
performance,  which  was  to  increase  the  storage  capacity.  It  has  also 
successfully  demonstrated  the  DBS  capability  of  providing  a  reasonable 
performance  approximation  of  the  WFI  system,  as  well  as  the 
manufacturing  systems. 

E.  ORGANIZATION 

This  report  is  organized  into  the  following  chapters  to  provide  a  structured  flow 
on  how  the  thesis  work  was  conceived  through  its  deliverable  end: 

•  Chapter  I  -  Introduction.  This  chapter  introduces  the  problem  statement 
and  provides  the  objective  and  scope  set  for  the  thesis  work.  It  also 
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provides  background  information  on  Project  SEA- 15  for  readers  to  better 
understand  the  basis  and  considerations  made  for  this  thesis  work,  as  well 
as  the  other  related  work  in  the  same  field. 

•  Chapter  II  -  Methodology.  This  chapter  describes  the  general 
methodology  adopted  for  this  work,  covering  the  development  approach, 
operation  analysis,  performance  measures  and  the  software  development 
environment. 

•  Chapter  III  -  Baseline  Airlift  Operation  Model.  This  chapter  describes  the 
purpose,  modeling  approach,  assumptions,  design  and  implementation  of 
the  baseline  airlift  operation  model,  including  the  simulation  findings. 

•  Chapter  IV  -  Final  Airlift  Operation  Model.  This  chapter  describes  the 
modeling  approach  and  differences  (versus  the  baseline  model),  and  the 
design  and  implementation  of  the  final  airlift  operation  model. 

•  Chapter  V  -  Testing  and  Verification.  This  chapter  describes  the  testing 
and  verification  work  conducted  for  the  final  airlift  operation  model. 

•  Chapter  VI  -  Design  of  Experiments.  This  chapter  describes  the  various 
experiments  conducted  to  demonstrate  the  final  airlift  operation  model’s 
capability,  compare  the  results  under  different  simulation  modes  and 
evaluate  the  load  transfer  capability  of  the  recommended  Phase  Zero  force. 

•  Chapter  VII  -  Conclusion.  This  chapter  summarizes  the  thesis  findings 
and  provides  recommendations  for  future  work  on  the  developed  model  to 
better  support  the  intended  objectives. 
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II.  METHODOLOGY 


A.  DEVELOPMENT  APPROACH 

An  iterative  development  approaeh  was  adopted  to  allow  for  a  baseline  model  to 
be  developed  quiekly  in  the  early  project  phase  based  on  available  information  to 
demonstrate  the  feasibility  of  using  DES  to  address  the  issues  under  study.  The  model 
could  then  be  used  as  the  platform,  if  still  applicable,  for  the  incremental  build  up  of  its 
details  and  capability  to  meet  the  end  objective.  The  adopted  approach  was  meant  to 
facilitate  the  refinement  and  realignment  of  the  software  model,  if  required,  as  more 
information  was  gathered  over  the  project  phase. 

For  the  baseline  model,  the  same  high-level  considerations  and  parameters  used  in 
Project  SEA- 15  were  adopted  so  as  to  first  verify  whether  an  alternative  DES  model 
could  produce  or  support  the  force  structure  solutions  as  recommended  by  that  project. 
Once  verified,  the  model  output  could  also  serve  as  a  proxy  for  Project  SEA- 15,  i.e.,  in 
areas  where  there  is  no  documented  information,  for  comparison  with  the  final  model 
output.  For  example,  the  project  report  only  stated  that  the  required  missions  could  be 
completed  within  the  given  time,  but  it  did  not  provide  the  expected  completion  time.  In 
order  to  cut  down  on  the  development  time,  existing  DES  components  developed  under 
the  OA3302  System  Simulation  course  work  will  be  utilized  to  formulate  the  baseline 
model. 

B.  OPERATION  ANALYSIS 

1.  Airlift  Operation  in  Project  SEA-15 

The  Civil  Support  mission  defined  in  Project  SEA- 15  was  comprised  of  two  key 
missions;  to  support  populace  life- sustenance  by  saving  lives  and  providing/  facilitating 
humanitarian  relief  assistance  to  the  victims,  and  to  restore  critical  infrastructure  so  as  to 
stabilize  the  affected  area  and  restore  it  to  normalcy  [1].  Airlift  support  is  essential  to 
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accomplish  these  missions,  being  the  only  means  for  transporting  the  required  resources 
into  the  affected  area  as  assumed  by  that  project,  i.e.,  taking  worst  case  situations  where 
all  other  forms  of  access  are  cut  off. 

Based  on  Project  SEA-15’s  final  recommended  force  structure,  the  platforms  that 
have  direct  involvement  in  the  air  operations  were  three  ship  classes,  namely  JMSDF 
DDK  class  destroyer,  LPD-17  and  JHSV,  and  the  two  helicopter  types:  CH-53K  and  SH- 
60S.  These  platforms  will  herein  be  referred  as  JMSDF,  LPD-17,  JHSV,  CH-53  and  SH- 
60  respectively.  The  project  has  identified  the  forces’  shipboard  cargo  capacity  and  its 
airlift  capacity  as  the  crucial  attributes  in  accomplishing  the  missions.  However,  the 
importance  of  the  shipboard  cargo  capacity  was  established  from  the  overall  sea-based 
storage  perspective  with  no  further  analysis  on  how  the  load  distribution  across  the  ships 
would  impact  the  actual  airlift  operation  in  executing  the  final  delivery  to  site. 

2.  Airlift  Operation  Process 

A  literature  research  was  conducted  on  the  airlift  operation  process  in  order  to 
identify  the  involved  elements  that  have  an  influential  effect  on  the  operation.  Several 
references  have  to  be  used  to  piece  together  the  process  that  is  of  relevance  to  the  study 
context  with  some  assumptions  made.  The  Shipboard-Helicopter  Operational  Procedures 
Manual  [9]  and  Multiservice  Helicopter  Sling  Load:  Basic  Operations  and  Equipment 
manual  [10]  were  the  two  main  reference  documents  used.  With  that,  the  airlift  operation 
workflow  was  broadly  categorized  into  six  phases  (elements)  as  summarized  below, 
supported  by  a  central  management  system  responsible  for  planning  and  coordinating  the 
involving  activities: 

•  Preparation  Phase.  This  is  the  phase  prior  to  the  aircraft  arrival,  where  the 
load  is  moved  to  the  landing  spot  from  the  holding  space  (if  necessary)  and 
set  up  for  the  loading  to  minimize  the  actual  load-up  time.  The  load  can 
be  airlifted  two  ways:  inside  the  aircraft  or  below  the  aircraft  suspended 
from  the  cargo  hook  (known  as  sling  load  operation)  [10].  For  this  study, 
the  load  type  and  its  airlift  methods  will  be  based  on  that  defined  for 
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Project  SEA- 15,  i.e.,  cargo  and  equipment  as  sling  load,  while  passengers 
are  to  be  transferred  inside  the  aircraft.  For  sling  load,  the  ground  crew 
must  check  to  ensure  that  the  load  is  properly  prepared,  rigged,  and 
inspected  for  sling  loading  [10]. 

•  Loading  Phase.  This  is  the  phase  where  the  aircraft  arrives  and  the  load  is 
physically  transferred  to  it.  For  sling  load  operation,  the  hook-up  team 
will  stay  by  the  load  for  the  hook-up  and  the  approaching  aircraft  will  be 
directed  into  position  over  the  load  by  a  signalman.  When  the  aircraft  gets 
in  position  and  is  in  steady  hover,  the  hook-up  team  will  perform  the  hook¬ 
up  and  ensure  that  the  connection  (cargo  hook  and  apex  fitting)  is  secured, 
while  grounding  the  cargo  hook  prior  to  any  contact  and  throughout  the 
process.  The  hook-up  team  will  then  get  clear  of  the  spot  and  the 
signalman  will  direct  the  aircraft  to  move  up  for  a  final  visual  check  on  the 
load  before  giving  the  take-off  signal  [10].  In  the  case  of  passenger 
loading,  the  aircraft  will  have  to  be  grounded  and  chocked,  at  minimum, 
when  the  ship  is  stationary  and  in  the  case  of  ship  underway,  TALON  or 
primary  tie  downs  will  have  to  be  used  before  transferring  passengers  [9]. 

•  Delivery  Phase.  This  is  the  phase  where  the  aircraft  delivers  the  load  from 
the  ship  to  the  designated  target  area.  With  sling  load  operations,  there 
may  be  restrictions  on  the  aircraft  airspeed  and  maneuvering  capabilities  in 
order  to  maintain  the  load  stability. 

•  Unloading  Phase.  This  is  the  phase  where  the  aircraft  arrives  at  the  target 
site  and  unloads.  The  landing  site  would  have  been  prepared  with  the 
ground  crew  standing  by  to  receive  the  load  prior  to  the  aircraft’s  arrival. 
Similar  to  the  lading  process,  the  aircraft  will  be  directed  into  position  by 
the  signalman  on  the  ground.  For  sling  load  operations  [11],  the  aircraft 
will  lower  the  load  to  the  ground  at  the  release  point  and  then  hover  to  one 
side  before  the  signalman  issues  the  “release  load”  sign  to  prevent  the  apex 
fitting  from  falling  on  the  load.  The  aircrew  are  generally  the  ones 
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opening  the  cargo  hook  to  release  the  load,  and  in  the  event  that  they  fail 
to  do  so,  the  ground  crew  will  step  in  to  manually  release  the  load.  Once 
the  load  is  properly  released,  the  aircraft  will  be  given  the  “take-off’  signal 
to  return  to  ship.  For  the  unloading  of  passengers,  the  aircraft  will  have  to 
be  grounded  without  the  need  for  chock  or  tie  downs. 

•  Recovery  Phase.  This  is  the  phase  where  the  aircraft  returns  to  the  ship 
from  the  designated  target  area.  At  this  juncture,  the  aircraft  would  have 
been  informed  of  which  ship  to  head  to  for  the  next  assignment  or  to  seek 
service  support. 

•  Servicing  Phase.  This  is  the  phase  where  the  aircraft  is  temporarily  “taken 
ouf  ’  of  the  mission  to  be  serviced.  There  are  two  aspects  to  the  servicing: 
refuel  and  repair.  Helicopter  refueling  operations  on  ships  can  either  be 
cold  (engines  off)  or  hot  (rotors  turning  or  engines  operating).  Cold 
refueling  may  be  accomplished  by  pressure  or  gravity  while  hot  refueling 
is  limited  to  the  use  of  pressure  only  [12].  Repair  (or  corrective 
maintenance)  is  necessary  when  the  aircraft  encounters  failure  and  is 
deemed  no  longer  “fit”  for  the  mission.  Most  helicopter  maintenance  is 
conducted  on  the  flight  deck  of  the  ship. 

In  a  multi-ship  environment,  the  airlift  aircraft  can  be  assigned  to  any  ship  to  pick 
up  the  load  so  long  as  the  loading  spot  can  accommodate  that  aircraft  type.  As  for 
servicing  support,  it  depends  on  whether  the  ship  has  the  facilities  set  up  to  support  that 
aircraft  type. 

The  final  airlift  operation  model  was  designed  based  on  this  abstraction  of  the 
process,  which  is  described  in  a  later  chapter. 
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c. 


PERFORMANCE  MEASURES 


1.  Primary  Measures 

The  performance  measures  defined  under  Project  SEA- 15  for  the  Civil  Support 
mission  would  naturally  be  included  for  the  models  developed  under  this  thesis  work, 
since  they  were  the  primary  parameters  of  immediate  importance  used  to  define  the  force 
structure;  they  are  described  in  the  following  subsections. 

(a)  Measure  of  Effectiveness  (MOE)  /  Measure  of  Performance 
(MOP)  for  Civil  Support  Mission 

As  highlighted  in  Chapter  I,  there  were  three  mission  scenarios  established 
for  the  Phase  Zero  force  to  support  the  Latin  American  populace  following  a  natural 
disaster  of  different  severity  levels.  Its  role  is  only  to  provide  “temporary  critical  support, 
while  a  more  suitable  and  substantial  force  can  be  formed  and  dispatched,  and  not  as 
complete  civil  relief’  [1].  The  MOEs  listed  in  the  following  table  were  defined  and  the 
associated  MOPs  are  detailed  in  the  next  table. 


S/N 

Performance  Measure 

Requirements 

A. 

Personnel  Supported 

1. 

Affected  population  to  be  assisted  for 

•  Low  Severity  Scenario 

50,000  pax 

•  Mean  Severity  Scenario 

100,000  pax 

•  High  Severity  Scenario 

150,000  pax 

2. 

Seriously  injured  medical  assistance: 

5%  of  affected  population 

B. 

Supply  Delivered 

3. 

Food 

2.5  lbs  per  person  per  day 

4. 

Water 

0.5  gal  per  person  per  day 

5. 

Shelter 

50%  of  population  affected 

Table  2.  MOE  For  Civil  Support  Mission  (after  [1]) 
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S/N 

Performance  Measure 

A. 

Personnel  Supported 

1. 

“Camp”  sites  provide  for  20,000  displaced  personnel  per  site. 

2. 

One  doctor  and  four  nurses  for  every  400  injured. 

3. 

One  surgeon  and  two  assistants  for  every  800  injured,  in  addition  to  the  doctors  and 
nurses  required. 

4. 

50%  of  doctors  accessed  off  site  via  telecommunications. 

B. 

Supply  Delivered 

5. 

First  supplies  to  be  delivered  within  24  hours. 

6. 

All  supplies  to  be  delivered  within  five  days. 

C. 

Overall 

7. 

Five-day  endurance  prior  to  subsequent  force  arrival. 

8. 

Penetration  inland  from  sea  (with  ships  stationed  five  nm  offshore)  for  : 

•  Low  Severity  Scenario:  five  miles 

•  Mean  Severity  Scenario  25  miles 

•  High  Severity  Scenario:  50  miles 

9. 

Sea  based  command  center  with  200nm  communications  range. 

10. 

Adequate  communications  capability  to  support  operations  including  remote  doctor 
telecom. 

Table  3.  MOP  For  Civil  Support  Mission  (after  [1]) 


(b)  Consolidated  Measures  for  Airlift  Operation 

Based  on  the  defined  MOE/MOP,  and  having  taken  into  eonsideration  the 
other  resourees  required  to  support  the  operation,  the  Project  SEA- 15  team  has  further 
consolidated  and  derived  the  following  sets  of  performance  measures  in  Table  4  to  be 
used  for  the  task  force.  The  measures  under  Section  C  of  the  table  are  the  ones  specific 
for  the  airlift  operation.  Essentially,  the  performance  measures  for  the  airlift  operation 
have  been  decomposed  to  the  maximum  delivery  rates  (per  day)  for  the  three  different 
load  types,  namely  cargo,  equipment  and  passengers. 
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S/N 

Parameters 

Scenario  Severity 

Unit 

Low 

Mean 

High 

A. 

Storage 

1. 

Store  (in  lbs) 

718,000 

1,429,500 

2,141,000 

lbs 

2. 

Store  (in  ft3) 

33,362 

66,458 

99,553 

ft3 

3. 

Vehicle 

2,220 

3,520 

5,780 

ft2 

B. 

Personnel 

170  (158) 

292 

506  (491) 

pax 

4. 

Medical 

43 

83 

123 

pax 

5. 

Marines 

127 

209 

383 

pax 

C. 

Airlift 

6. 

Max  Cargo 

413,600 

825,900 

1,238,200 

Ibs/day 

7. 

Max  Equipment 

6 

11 

16 

sets/day 

8. 

Max  Passenger 

32 

72 

99 

pax/day 

Table  4.  Consolidated  Measures  For  Civil  Support  Mission  (after  [1]) 


2.  Detailed  Measures 

Based  on  the  airlift  operation  proeess  described  in  earlier  sections,  the  following 
are  the  additional  parameters  deemed  essential  for  measuring  operation  effectiveness 
and/or  providing  insights  to  the  operation  workflow  efficiency  for  conducting 
operational/tactical  level  analysis,  and  hence  incorporated  in  the  final  model: 

•  Mission  Completion  Time.  This  is  time  taken  for  all  the  loads  to  be 
delivered  to  the  designated  target  site  (or  affected  area). 

•  Mission  Sorties.  This  is  the  total  number  of  delivery  sorties  flown  in  order 
to  transport  all  the  loads  to  the  designated  target  site  with  breakdown  for 
each  aircraft  type. 

•  Aircraft  Utilization.  This  is  the  overall  utilization  rate  for  all  airlift  aircraft 
in  the  task  force  over  a  mission  day  with  breakdown  for  each  aircraft  type. 
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The  “idle”  state  is  defined  as  the  period  where  the  aircraft  is  ready  for  a 
delivery  sortie  but  with  no  assignment  given. 

•  Landing  Spot  Utilization.  This  is  the  overall  utilization  rate  for  all  landing 
spots  onboard  the  ships  over  a  mission  day  with  breakdown  for  each  ship. 
The  “idle”  state  is  defined  as  the  period  where  the  landing  spot  is  not  used 
for  any  ongoing  activity  or  in  standby  (planned)  for  an  impending  activity. 

•  Crew  Utilization.  This  is  the  overall  utilization  rate  for  all  logistics  crew 
onboard  the  ship  over  a  mission  day  with  breakdown  for  each  ship.  The 
“idle”  state  is  defined  as  the  period  where  the  crew  is  not  supporting  any 
ongoing  activity. 

•  Duration  of  Aircraft  in  Various  Operation  Phases.  This  is  the  average  time 
the  aircraft  spent  in  a  particular  phase  of  the  operation  (e.g.,  delivery, 
recovery,  etc.)  over  a  mission  day. 

•  Load  Delivered  Over  Time.  This  is  the  quantity  of  the  various  load  types 
delivered  to  the  designated  target  sites  measured  at  fixed  time  intervals 
over  a  mission  day. 

The  baseline  model  was  not  meant  to  support  this  level  of  analysis  by  objective. 

D.  SOFTWARE  DEVELOPMENT  ENVIRONMENT 

The  following  are  the  software  tools  and  development  environment  used  for 
constructing  the  models. 

1.  Java 

Java  is  a  free,  open-source  High  Level  Language  (HLL)  developed  by  Sun 

Microsystems  and  released  in  1995  as  a  core  component  of  Sun  Microsystems'  Java 

platform.  The  language’s  syntax  is  very  much  derived  from  C  and  C++  but  has  a  simpler 

object  model  and  fewer  low-level  facilities.  Portability  is  the  key  strength  of  Java,  which 

allows  applications  written  in  the  language  to  run  similarly  on  any  supported 

hardware/operating-system  platform.  This  is  achieved  by  compiling  the  Java  language 
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code  to  bytecode  (class  fde)  instead  of  directly  to  platform-specific  machine  code,  which 
can  be  run  on  any  Java  Virtual  Machine  (JVM)  regardless  of  computer  architecture.  End- 
users  will  use  a  Java  Runtime  Environment  (JRE)  installed  on  their  own  machine  for 
standalone  Java  applications,  or  in  a  Web  browser  for  Java  applets  [13]. 

2.  Simkit 

Simkit  is  a  free,  open-source  programming  toolkit  developed  by  Professor  Arnold 
Buss  of  NPS  to  create  DES  models  from  an  Event  Graph  methodology,  i.e.,  the  simplest 
and  most  natural  way  of  presenting  the  model.  It  is  written  in  Java  and  runs  on  any  Java 
2  platform  and  modem  Web  browsers,  and  is  installable  from  the  Web  [14]. 

Every  element  in  an  Event  Graph  model  has  a  corresponding  element  in  Simkit, 
which  uses  a  component  framework  based  on  a  listener  design  pattern.  Basic  models 
encapsulating  a  single  Event  Graph  are  implemented  in  Simkit  by  subclassing  the 
SimEntityBase  class,  i.e.,  an  abstract  base  class  that  implements  most  of  the  functionality 
required  by  a  DES  component.  The  component  framework  relies  on  two  forms  of  the 
Listener  Pattern,  the  SimEventListener  and  the  PropertyChangeListener  patterns,  to  allow 
modelers  to  connect  the  basic  models  together  to  create  larger  models  of  greater 
complexity.  This  component  framework  is  called  Listener  Event  Graph  Objects  (LEGO). 
Figure  3  illustrates  the  conceptual  design  on  how  two  basic  components,  i.e..  Arrival 
Process  and  Multi-Server  Queue,  are  linked  through  a  SimEventListener  to  create  a 
simple  queuing  model  using  Simkit  [15]. 

Simkit  also  incorporates  a  framework  for  generating  random  variates  and  numbers 
to  support  simulation  using  different  probability  distributions  without  the  need  for  any  re- 
editing  of  the  source  code  and  recompilation.  This  capability  is  particularly  important  for 
the  LEGO  framework  as  it  is  undesirable  to  have  every  conceivable  random  variable 
implemented  as  a  different  component  class  [15]. 
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3.  NetBeans  Integrated  Development  Environment  (IDE) 

NetBeans  [17]  is  a  free,  open-source  IDE  for  software  developers  that  is  easy  to 
install  and  use  straight  out  of  the  box  and  runs  on  multiple  platforms  including  Windows, 
Linux,  Mac  OS  X  and  Solaris.  It  comes  with  a  suite  of  tools  that  allows  developers  to 

•  create  professional  desktop  applications  using  its  GUI  Builder  with  Swing 
Application  Framework  and  Beans  Binding  support, 

•  build  Web  applications  using  Ajax,  JavaScript  and  CSS  with  support  for 
frameworks  including  JSF,  Struts,  Spring,  and  Hibernate, 

•  create,  test  and  debug  GUI  applications  that  run  on  mobile  phones,  set-top 
boxes,  and  PDAs,  with  support  for  JavaFX  Mobile  and  the  Java  ME  SDK 
3.0  Platform,  and 

•  create  open-source  projects  and  host  them  on  Kenai.com. 

NetBeans  features  language-aware  editors  for  JavaFX,  JavaScript,  CSS,  Python, 


PHP,  Groovy  and  Grails,  Ruby  and  Ruby  on  Rails,  including  code  completion, 
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documentation  pop-ups,  and  debugging  integration.  It  also  incorporates  C/C++  editor, 
debugger,  project  templates,  support  for  multiple  project  configurations,  remote 
development,  and  packaging  of  completed  projects. 
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III.  BASELINE  AIRLIFT  OPERATION  MODEL 


A.  DESIGN 

As  highlighted  in  Chapter  II,  the  baseline  model  was  meant  to  be  a  simplified 
model  that  can  be  quickly  assembled  to  capture  the  essence  of  the  study  question  scenario 
in  order  to  set  one’s  bearing.  The  model  is  essentially  designed  based  on  the  queuing 
concept  with  parallel-servers  and  multiple  customer  types.  In  this  case,  the  aircraft  are 
modeled  as  the  “servers”  and  the  load  as  the  “customers,”  as  described  below: 

•  The  different  loads  are  generated  at  the  onset  of  the  simulation  and  form 
their  respective  queues  waiting  to  be  to  be  airlifted  (served)  as  and  when 
the  aircraft  are  available. 

•  The  number  of  loads  that  can  be  airlifted  per  sortie  (service)  is  subject  to 
the  aircraft’s  capacity. 

•  The  service  duration  is  the  round-trip  travel  time  taken  to  cover  the 
distance  between  the  ship  and  the  target  area,  based  on  the  aircraft  speed 
for  each  leg  (an  aircraft  flies  slower  when  it  carries  a  sling  load)  plus  the 
loading  and  unloading  time. 

•  The  queue  that  can  be  served  will  depend  upon  the  aircraft’s  airlift 
capability.  For  example,  SH-60  is  incapable  of  airlifting  equipment  [1] 
and  hence  will  not  serve  that  particular  queue. 

•  The  queue  to  serve  first  (i.e.,  load-to-aircraft  assignments)  will  further 
depend  on  the  aircraft’s  relative  transfer  advantage,  in  terms  of  their 
capacity  ratio,  so  as  to  optimize  the  airlift  resources.  For  example,  while 
the  SH-60  has  lower  absolute  capacities  in  transporting  both  passengers 
and  cargo,  as  compared  to  CH-53,  it  is  relatively  more  efficient  for 
carrying  passengers  based  on  the  capacity  ratio  of  12-55  (pax)  versus 
4,500-27,000  (lbs)  respectively.  For  this  reason,  the  SH-60  will  always 
serve  the  passengers  first. 
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The  simulation  will  ran  and  stop  in  accordance  with  the  duration  defined,  which 
in  this  case  is  modeled  as  the  daily  operating  hours  for  airlift  operation. 

B.  ASSUMPTIONS 

Based  on  the  above-mentioned  design  concept,  the  following  are  the  further 
considerations  and  assumptions  made,  which  are  consistent  with  those  made  in  Project 
SEA- 15  [1]  where  applicable: 

•  Only  aircraft  types  in  the  recommended  force  structures  were  modeled, 
i.e.,  SH-60  and  CH-53. 

•  The  airlift  operation  was  modeled  on  a  daily-operation  basis  and,  in  this 
case,  to  meet  the  maximum  delivery  rate  as  required  for  the  task  force, 
based  on  the  defined  scenarios. 

•  The  load  hook-up,  delivery,  drop-off  and  recovery  for  each  aircraft  sortie 
are  collapsed  and  treated  as  a  single  round-trip  process  with  a  deterministic 
time  factor  that  is  only  dependent  on  the  load  type  for  each  defined 
mission  scenario. 

•  The  loads  are  consolidated  and  supplied  from  a  single  source  (disregarding 
the  fact  that  they  could  be  stored  on  different  ships). 

•  All  load  types  are  ready  and  waiting  to  be  airlifted  at  the  landing  spots. 

•  There  are  unlimited  landing  spots,  i.e.,  all  aircraft  can  perform  hook-ups 
concurrently. 

•  The  refueling  time  for  each  aircraft  is  treated  as  a  single  time  block 
(regardless  of  the  number  of  refueling  operations),  deducted  from  the  daily 
operating  hours. 

•  The  expected  failure  and  repair  time  for  each  aircraft  type  are  accounted 
for  using  operational  availability  to  pro-rate  the  “usable  hours”  based  on 
the  reduced  operating  hours  (i.e.,  after  deducting  the  refueling  time). 
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•  A  basic  set  of  statistical  utilities  are  incorporated  to  generate  data  similar 
to  those  from  the  Project  SEA- 15  so  that  comparisons  can  be  made. 

C.  IMPLEMENTATION 

The  baseline  airlift  operation  model  is  implemented  in  Simkit.  It  is  comprised  of 
two  components,  the  LoadCreator  and  AirliftServer.  The  SimEventListener  structure  is 
depicted  in  Figure  4.  The  parameters  and  state  variables  for  the  model  are  listed  in  the 
next  two  tables  (which  will  be  referenced  in  the  follow-on  event  graphs)  with  the  model 
component  details  provided  in  the  subsequent  subsections. 


Load 

Creator 


Airlift 

Servers 


Figure  4.  SimEventListener  Structure  for  Baseline  Airlift  Operation  Model 


S/N 

Field 

Parameters 

1. 

Hi 

Total  number  to  be  transferred  for  each  load  type  i,  i.e.,  i  =  0,  1  and  2  for 
cargo,  equipment  and  passengers  respectively. 

data  type:  int 

2. 

ts(CH)J 

Sequence  of  possibly  random  service  times  (i.e.,  sortie  times)  for  CH-53 
aircraft  type  to  transfer  load  type  i. 

data  type:  simkit. random.RandomVariate 

3. 

ts(SH)_i 

Sequence  of  possibly  random  service  times  (i.e.,  sortie  times)  for  SH-60 
aircraft  type  to  transfer  load  type  i. 

data  type:  simkit. random.RandomVariate 

4. 

CcH_i 

Transfer  capacity  of  CH-53  aircraft  type  for  load  type  i. 

data  type:  int 

5. 

CsH_i 

Transfer  capacity  of  SH-60  aircraft  type  for  load  type  i. 

data  type:  int 

6. 

kcH 

Total  number  of  CH-53  aircraft  type. 
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S/N 

Field 

Parameters 

data  type:  int 

7. 

ksH 

Total  number  of  SH-60  aireraft  type. 

data  type:  int 

Table  5.  Parameters  for  Baseline  Airlift  Operation  Model 


S/N 

Field 

State  Variables 

1. 

Ni 

Number  of  arrivals  for  load  type  i,  i.e.,  i  =  0,  1  and  2  for  cargo,  equipment 
and  passenger  respectively;  initial  value  is  0. 

data  type:  int 

2. 

Qi 

Remaining  quantity  of  load  type  i;  initial  value  is  0. 

data  type:  int 

3. 

Mi 

Quantity  transferred  for  load  type  i;  initial  value  is  0. 

data  type:  int 

4. 

Sen 

Number  of  available  CH-53  aircraft  type  for  load  transfer;  initial  value  is 

klVIH- 

data  type:  int 

5. 

SsH 

Number  of  available  SH-60  aircraft  type  for  load  transfer;  initial  value  is 
ksH- 

data  type:  int 

6. 

Fch 

Number  of  CH-53  sorties  flown  (i.e.,  took  off);  initial  value  is  0. 

data  type:  int 

7. 

Fsh 

Number  of  SH-60  sorties  flown  (i.e.,  took  off);  initial  value  is  0. 

data  type:  int 

8. 

UcH 

Cumulative  flight  time  for  the  CH-53  sorties  flown;  initially  undefined. 

data  type:  double 

9. 

USH 

Cumulative  flight  time  for  the  SH-60  sorties  flown;  initially  undefined. 

data  type:  double 

10. 

T 

Mission  time  based  on  the  last  completed  sortie;  initially  undefined. 

data  type:  double 

Table  6.  State  Variables  for  Baseline  Airlift  Operation  Model 
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1. 


LoadCreator  Component 


The  component  is  responsible  for  creating  all  the  loads  for  the  three  different  load 
types  at  the  simulation  onset  and  passing  the  individual  load  items  to  the  AirliftServers  as 


and  when  they  are  created.  The  following  figure  depicts  the  component  event  graph  and 
the  specific  events  are  described  in  Table  7. 


(i<no-I) 


{N2=N2+  1} 


Figure  5.  Event  Graph  for  LoadCreator  Component 
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S/N 

Event 

Description 

1. 

Run 

Performs  initialization  of  all  load  type  arrivals  (Ni)  to  zero  and 
immediately  triggers  the  other  three  events  at  the  start  of 
simulation. 

2. 

ArrivalBatchjO 

Creates  individual  cargo  item  and  passes  it  to  AirliftServers.  The 
total  transfer  quantity  is  created  by  looping  through  the  event  for 
that  number  of  times. 

3. 

ArrivalBatch_l 

Same  as  ArrivalBatchjO  event  but  for  equipment  load  type. 

4. 

ArrivalBatch_2 

Same  as  ArrivalBatchjO  event  but  for  passenger  load  type. 

Table  7.  Events  for  LoadCreator  Component 


2.  AirliftServers  Component 

The  component  is  responsible  for  modeling  the  whole  airlift  operation  for  both 
aircraft  types.  The  sequential  arrivals  of  the  load  (at  time  0)  will  trigger  the  appropriate 
aircraft  to  start  their  respective  airlift  operations  when  the  mounting  numbers  in  the  queue 
reaches  the  aircraft  capacity  or  at  the  end  of  the  load  arrivals.  The  remaining  number  in 
queue  (Qt+i)  after  each  new  sortie  is  computed  using  the  max  function,  i.e.,  picking  the 
maximum  between  0  and  the  value  of  subtracting  the  load  capacity  (c)  from  the 
remaining  number  in  queue  (Qt),  as  depicted  by  the  following  mathematical  notation: 


Qt +  i  =  max(0,  (Q,-c)) 


The  load  transfer  amount  (jt)  will  either  be  the  load  capacity,  if  the  remaining 
existing  number  in  queue  is  bigger  than  the  load  capacity,  or  otherwise,  the  existing 
number  in  queue,  as  depicted  by  the  following  mathematical  notation: 


{c,Q,>c 
[Q,,  otherwise 


The  following  figure  depicts  the  component  event  graph  and  the  specific  events 
are  described  in  Table  8. 
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Figure  6.  Event  Graph  for  AirliftServers  Component 
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S/N 

Event 

Description 

1. 

Run 

Performs  initialization  for  the  following  state  variables: 

•  initialize  remaining  quantity  for  each  load  type  (QO  to  zero 

•  initialize  transferred  quantity  for  each  load  type  (Mi)  to  zero 

•  initialize  number  of  available  CH-53  aircraft  type  (Sen)  to  its 
total  number  (kcu) 

•  initialize  number  of  available  SH-60  aircraft  type  (Ssh)  to  its 
total  number  (ksn) 

•  initialize  number  of  CH-53  sorties  flown  (Fch)  to  zero 

•  initialize  number  of  SH-60  sorties  flown  (Fsh)  to  zero 

•  initialize  mission  time  for  last  completed  sortie  (T)  to  zero 

2. 

ArrivalBatchO 

Listens  for  cargo  item  arrival  from  LoadCreator  and  increments 
the  remaining  quantity  (Qo)  each  time. 

Triggers  the  appropriate  StartService  event  and  provides  the  load 
type  identifier  if  the  conditions  are  met,  which  is  dependent  on 
the  available  aircraft  capability  and  capacity,  as  well  as  what 
other  load  types  are  left  to  be  transferred  (as  discussed  under  the 
design  concept). 

3. 

ArrivalBatch_l 

Same  as  ArrivalBatchjO  event  but  for  equipment  load  type. 

4. 

ArrivalBatch_2 

Same  as  ArrivalBatchjO  event  but  for  passenger  load  type. 

5. 

StartServiceCH 

Commences  an  airlift  sortie  for  CH-53  aircraft  and  performs  state 
transition  for  the  following  variables: 

•  decrease  number  of  available  CH-53  aircraft  type  (Sen)  by 
one 

•  increase  number  of  CH-53  sorties  flown  (Fch)  by  one 

•  decrease  remaining  quantity  for  the  load  type  (Qi)  using  max 
function,  i.e.,  Qt  +  i  =  max(0,  (Q.  -  c)) 

Computes  load  transfer  amount  (j)  using  the  cited  formula,  i.e., 

.  \c,Q,>c 

J‘~] 

[Q,,  otherwise 

Triggers  EndServiceCH  event  after  ts(CH)  i  time  delay,  passing 
load  transfer  amount  and  load  type  identifier  as  argument. 

6. 

EndServiceCH 

Completes  the  airlift  sortie  for  CH-53  aircraft  and  performs  state 
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S/N 

Event 

Description 

transition  for  the  following  variables: 

•  increase  number  of  available  CH-53  aircraft  type  (SCH)  by 
one 

•  increase  transferred  quantity  for  the  load  type  (Mi)  by  the 
load  transfer  amount  (j) 

•  timestamp  the  mission  time  for  last  completed  sortie  (T) 

Triggers  StartServiceCH  event  immediately  and  provides  the 
load  type  identifier  if  the  conditions  are  met,  depending  on  the 
aircraft’s  capability  and  its  priority  load,  as  well  as  the  remaining 
load  quantity. 

7. 

StartServiceSH 

Same  as  StartServiceSH  event  but  for  SH-60  aircraft  type. 

8. 

EndServiceSH 

Same  as  EndServiceSH  event  but  for  SH-60  aircraft  type. 

Table  8.  Events  for  AirliftServers  Component 


D.  TESTING  SETUP  AND  RESULTS 

1.  Input  Data 

As  the  main  objective  is  to  verify  whether  the  alternative  DES  approach  would 
support  Project  SEA- 15  findings  on  the  recommended  force  structure  using  future  force 
assets,  the  testing  has  adopted  the  same  input  data  as  the  project  [1],  Table  9  depicts  the 
aircraft  parameters,  and  Table  10  summarizes  the  scenario  requirements  and  settings,  as 
well  as  the  computed  capability  for  the  force  structure.  The  capability  is  essentially 
measured  by  the  excess  capacity  for  transferring  the  cargo  load  type,  conditional  on 
meeting  the  transfer  requirements  for  the  other  two  load  types,  based  on  the  data  that  was 
presented  in  Project  SEA- 15  report. 

The  testing  was  performed  for  all  three  scenarios  against  the  suggested 
capabilities  for  the  force  structure  (Section  B  of  Table  10)  based  on  the  7.65  effective 
operating  hours  for  the  day.  In  other  words,  the  suggested  capacities  for  the  various  load 
types  are  injected  into  the  model  as  the  quantities  to  be  transferred  within  the  defined 
time.  A  comparison  can  then  be  made  with  the  model  outputs,  based  on  the  quantity 

delivered,  resource  utilization  and  any  additional  comments  generated  by  the  model. 
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S/N 

Parameters 

SH-60 

CH-53 

A. 

Capacity  and  Capability 

11. 

For  Cargo 

4,500  lbs 

27,000  lbs 

12. 

For  Equipment 

Not  Capable 

2  sets 

13. 

For  Personnel 

12  pax 

55  pax 

Table  9.  Aircraft  Parameter  Input  Data  for  Baseline  Airlift  Operation  Model 


S/N 

Scenario 

Scenario  Severity 

Low 

Mean 

High 

A. 

Load  Transfer  Requirement 

1. 

For  Cargo  (lbs) 

413,600 

825,900 

1,238,200 

2. 

For  Equipment  (sets) 

6 

11 

16 

3. 

For  Personnel  (pax) 

32 

72 

99 

B. 

Load  Transfer  Capability 

4. 

For  Cargo  (lbs) 

1,300,000 

(314%) 

855,000 

(103%) 

1,377,000 

(111%) 

5. 

For  Equipment  (sets) 

6  (100%) 

11  (100%) 

16  (100%) 

6. 

For  Personnel  (pax) 

32  (100%) 

72  (100%) 

99  (100%) 

C. 

Aircraft  Quantity  (i.e.,  the  force  structure  recommended) 

7. 

For  CH-53  (ea) 

1 

2 

7 

8. 

For  SH-60  (ea) 

2 

2 

2 

D. 

Operating  Profile 

9. 

Normal  Operating  Hours  (hr) 

12 

10. 

Refuel  Time  and  Non-Mission 
Overheads  (hr) 

3 

11. 

Operational  Availability  (Ao) 

0.85 

12. 

Effective  Operating  Hours  (hr) 

[i.e.,((9)-(10))*(ll)] 

7.65 
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S/N 

Scenario 

Scenario  Severity 

Low 

Mean 

High 

D. 

Round-Trip  Time  for  CH-53 

13. 

For  Cargo  (hr) 

0.11 

0.51 

0.91 

14. 

For  Equipment  (hr) 

0.11 

0.51 

0.91 

15. 

For  Personnel  (hr) 

0.23 

0.52 

0.81 

D. 

Round-Trip  Time  for  SH-60 

16. 

For  Cargo  (hr) 

0.13 

0.61 

1.10 

17. 

For  Equipment  (hr) 

N.A. 

N.A. 

N.A. 

18. 

For  Personnel  (hr) 

0.24 

0.58 

0.92 

Table  10.  Scenario  Requirement  Input  Data  for  Baseline  Airlift  Operation  Model  (after  [1]) 

The  round-trip  time  for  transferring  personnel  is  relatively  longer  versus  the  other 
two  load  types  for  the  low  severity  scenario,  and  shorter  for  the  high  severity  scenario. 
This  is  because  the  round-trip  time  has  a  fixed  loading/unloading  time  component  and  a 
varying  traveling  time  component,  which  is  distance-dependent.  As  the  higher  severity 
scenarios  have  a  longer  associated  travel  distance,  the  resultant  round-trip  time  for 
transporting  passengers  becomes  relatively  shorter  due  to  its  longer  loading/unloading 
time. 


2.  Simulation  Results 

The  following  figures  are  the  output  results  generated  by  the  model  for  the  three 
test  scenarios.  Table  11  summarizes  the  test  results  with  comparison  to  the  suggested 
capability  from  Project  SEA- 15. 
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Simulation  duration  set:  7.65  hours 

CH-53 

SH-60 

Total 

Number  of  platforms  deployed  : 

1 

2 

3 

Cargo  transferred  (in  lbs)  : 

1007500 

292500 

1300000  (100%) 

Equipment  transferred  (in  sets)  : 

6 

N.A. 

6  (100%) 

Passengers  transferred  (in  pax)  : 

0 

32 

32  (100%) 

Sorties  flown  : 

41 

68 

109 

Average  Utilization  : 

60.43% 

59.76% 

60.09% 

Number  of  cargo  left  : 

0  lbs 

Number  of  equipment  left  : 

0  sets 

Number  of  passengers  left  : 

0  pax 

All  loads  have  been  transferred. 

Time  last  sortie  completed  delivery  : 

4.62  hours 

Figure  7.  Results  for  Low  Severity  Scenario  using  Baseline  Airlift  Operation  Model 

based  on  Project  SEA- 15  Findings 


Simulation  duration  set:  7.65  hours 

CH-53 

SH-60 

Total 

Number  of  platforms  deployed  : 

2 

2 

4 

Cargo  transferred  (in  lbs)  : 

648000 

81000 

729000  (85%) 

Equipment  transferred  (in  sets)  : 

11 

N.A. 

11  (100%) 

Passengers  transferred  (in  pax)  : 

0 

72 

72  (100%) 

Sorties  flown  : 

32 

26 

58 

Average  Utilization  : 

100.00% 

100.00% 

100.00% 

Number  of  cargo  left  : 

63000  lbs 

Number  of  equipment  left  : 

0  sets 

Number  of  passengers  left  : 

0  pax 

There  are  still  loads  in  transition. 

Time  last  sortie  completed  delivery  : 

7.65  hours 

Figure  8.  Results  for  Mean  Severity  Scenario  using  Baseline  Airlift  Operation  Model 

based  on  Project  SEA- 15  Findings 
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Simulation  duration  set:  7.65  hours 

CH-53 

SH-60 

Total 

Number  of  platforms  deployed  : 

7 

2 

9 

Cargo  transferred  (in  lbs)  : 

1296000 

22500 

1318500  (95%) 

Equipment  transferred  (in  sets)  : 

16 

N.A. 

16  (100%) 

Passengers  transferred  (in  pax)  : 

0 

99 

99  (100%) 

Sorties  flown  : 

58 

16 

74 

Average  Utilization  : 

96.31% 

100.00% 

98.15% 

Number  of  cargo  left  : 

0  lbs 

Number  of  equipment  left  : 

0  sets 

Number  of  passengers  left  : 

0  pax 

There  are  still  loads  in  transition. 

Time  last  sortie  completed  delivery  : 

7.25  hours 

Figure  9.  Results  for  High  Severity  Scenario  using  Baseline  Airlift  Operation  Model 

based  on  Project  SEA- 15  Findings 


S/N 

Parameters 

SEA-15 

Baseline  Model  Results 

Capability 

Capability 

Resource  UtiUzation 

A. 

Low  Severity  Scenario 

1. 

Cargo  (lbs) 

1,300,000 

1,300,000 

(100%) 

660.09% 

2. 

Equipment  (sets) 

6 

6  (100%) 

3. 

Passenger  (pax) 

32 

32  (100%) 

B. 

Mean  Severity  Scenario 

4. 

Cargo 

855,000 

729,000  (85%) 

1100.00% 

5. 

Equipment 

11 

11  (100%) 

6. 

Passenger 

72 

72  (100%) 

C. 

High  Severity  Scenario 

7. 

Cargo 

1,3770,000 

1,318,500 

(95%) 

98.15% 

8. 

Equipment 

16 

16  (100%) 
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S/N 

Parameters 

SEA-15 

Baseline  Model  Results 

Capability 

Capability 

Resource  Utilization 

9. 

Passenger 

99 

99  (100%) 

Table  11.  Test  Results  for  Baseline  Airlift  Operation  Model  versus  Project  SEA- 15 

Reported  Data 


The  test  results  have  shown  inconsistencies  with  the  findings  from  Project  SEA-15: 

•  For  the  low  severity  scenario,  the  model  is  able  to  deliver  all  the  loads 
within  the  given  timeline  but  the  low  resource  utilization  rate  of  about 
60%  suggested  that  the  task  force  is  capable  of  delivering  more  load,  i.e.. 
Project  SEA- 15  could  have  under-specified  the  transfer  capability. 

•  For  the  mean  severity  scenario,  the  resource  utilization  rate  is  100%  but 
the  cargo  quantity  delivered  is  only  85%,  suggesting  that  Project  SEA- 15 
could  have  over- specified  the  transfer  capability  in  this  case. 

•  Similar  to  the  high  severity  scenario,  the  cargo  quantity  delivered  did  not 
meet  100%,  but  in  this  case,  the  resource  utilization  is  at  98.15%.  Based 
on  the  additional  information  generated  by  the  model  output  (refer  Figure 
8),  i.e.,  the  observed  number  of  cargo  left  being  zero  and  the  comment  that 
“there  are  still  loads  in  transition,”  it  can  now  be  inferred  that  all  loads 
have  already  been  picked  up  but  delivery  is  incomplete  because  there  are 
still  delivery  sorties  transiting  to  the  target  site.  This  explains  why  the 
utilization  rate  is  not  100%,  as  some  aircraft  would  have  completed  their 
last  delivery  sorties  and  were  in  “idle”  state  when  the  simulation  ended. 
Again,  this  suggested  an  over-specification  by  Project  SEA- 15  on  the 
transfer  capability. 

Given  that  these  inconsistencies  were  found,  a  thorough  verification  was 
conducted  on  the  model  algorithms  as  well  as  the  Project  SEA- 15  reported  data. 
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3.  Verification  Findings 

The  verification  work  has  shown  that  the  capability  figures  presented  in  the 
Project  SEA- 15  report  were  incorrect,  based  on  mathematical  computation  and 
optimization  analysis  using  linear  programming.  The  optimization  model  was  formulated 
using  the  Solver  utility  in  Windows  Excel  software  and  the  input  parameters  were  based 
on  the  same  ones  used  by  Project  SEA- 15  and  the  baseline  airlift  model  as  summarized  in 
the  earlier  tables  (Table  9  and  Table  10). 

For  the  high  severity  scenario  case,  the  load  transfer  capabilities  for  the  various 
load  types,  and  the  maximum  number  of  CH-53  sorties  that  can  be  conducted  (and 
completed)  within  the  given  timeline  were  used  as  the  constraints  for  the  optimization 
model  to  determine  the  minimum  number  of  SH-60  sorties  required.  Fifty-six  CH-53 
sorties  (48  and  eight  for  transporting  cargo  and  equipment  respectively)  and  27  SH-60 
sorties  (18  and  nine  for  transporting  cargo  and  passengers  respectively)  were  the  output 
figures  computed  by  the  model.  By  summing  up  the  timings  required  for  each  of  these 
sorties,  it  can  be  shown  that  1,377,000  lbs  of  cargo  cannot  be  delivered  within  7.65  hrs 
while  meeting  the  transfer  capabilities  for  the  other  two  load  types.  The  following  table 
illustrates  the  required  sorties  that  would  have  been  imposed  on  each  aircraft  in  order  to 
meet  the  stated  capabilities,  which  clearly  shows  that  the  two  SH-60s  will  not  complete 
the  sorties  in  time. 
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Table  12.  Example  of  the  Aireraft  Sorties  Required  to  meet  the  Load  Transfer  Capability 
stated  in  Projeet  SEA- 15  Report  for  High  Severity  Seenario 

Using  the  same  methodology,  the  eapability  figures  stated  in  the  Project  SEA- 15 
report  for  the  low  and  mean  severity  scenarios  were  also  proven  to  be  incorrect,  as 
suggested  by  the  baseline  airlift  model. 

The  same  methodology  was  also  applied  to  the  baseline  airlift  model  to  verify  its 
output  results.  For  the  mean  and  high  severity  scenarios,  the  figures  for  the  cargo 
quantity  delivered  in  Figure  8  and  Figure  9,  i.e.,  729,000  and  1,318,500  lbs  respectively, 
were  used  as  input  to  the  model  so  as  to  generate  the  required  sorties  to  be  verified  by  the 
optimization  model.  For  the  low  severity  scenario  case,  a  direct  mathematical  calculation 
suggested  that  the  cargo  transfer  capability  should  be  2,232,000  lbs,  which  was  injected 
to  the  model  to  generate  the  required  output  for  verification.  The  next  three  figures  are 
the  results  from  the  airlift  model,  and  Table  13  summarizes  the  sorties  required,  with  a 
comparison  to  that  generated  by  the  optimization  model. 
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Simulation  duration  set:  7.65  hours 

CH-53 

SH-60 

Total 

Number  of  platforms  deployed  : 

1 

2 

3 

Cargo  transferred  (in  lbs)  : 

1728000 

504000 

2232000  (100%) 

Equipment  transferred  (in  sets)  : 

6 

N.A. 

6  (100%) 

Passengers  transferred  (in  pax)  : 

0 

32 

32  (100%) 

Sorties  flown  : 

67 

115 

182 

Average  Utilization  : 

98.75% 

99.64% 

99.19% 

Number  of  cargo  left  : 

0  lbs 

Number  of  equipment  left  : 

0  sets 

Number  of  passengers  left  : 

0  pax 

All  loads  have  been  transferred. 

Time  last  sortie  completed  delivery  : 

7.64  hours 

Figure  10.  Force  Structure  Capability  for  Low  Severity  Scenario  using  Baseline  Airlift 

Operation  Model 


Simulation  duration  set:  7.65  hours 

CH-53 

SH-60 

Total 

Number  of  platforms  deployed  : 

2 

2 

4 

Cargo  transferred  (in  lbs)  : 

648000 

81000 

729000  (100%) 

Equipment  transferred  (in  sets)  : 

11 

N.A. 

11  (100%) 

Passengers  transferred  (in  pax)  : 

0 

72 

72  (100%) 

Sorties  flown  : 

30 

24 

54 

Average  Utilization  : 

99.96% 

94.59% 

97.27% 

Number  of  cargo  left  : 

0  lbs 

Number  of  equipment  left  : 

0  sets 

Number  of  passengers  left  : 

0  pax 

All  loads  have  been  transferred. 

Time  last  sortie  completed  delivery  : 

7.65  hours 

Figure  1 1 .  Force  Structure  Capability  for  Mean  Severity  Scenario  using  Baseline  Airlift 

Operation  Model 
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Simulation  duration  set:  7.65  hours 

CH-53 

SH-60 

Total 

Number  of  platforms  deployed  : 

7 

2 

9 

Cargo  transferred  (in  lbs)  : 

1296000 

22500 

1318500  (100%) 

Equipment  transferred  (in  sets)  : 

16 

N.A. 

16  (100%) 

Passengers  transferred  (in  pax)  : 

0 

99 

99  (100%) 

Sorties  flown  : 

56 

14 

70 

Average  Utilization  : 

94.83% 

89.61% 

92.22% 

Number  of  cargo  left  : 

0  lbs 

Number  of  equipment  left  : 

0  sets 

Number  of  passengers  left  : 

0  pax 

All  loads  have  been  transferred. 

Time  last  sortie  completed  delivery  : 

7.25  hours 

Figure  12.  Force  Structure  Capability  for  High  Severity  Scenario  using  Baseline  Airlift 

Operation  Model 


Table  13.  Test  Results  Comparison  for  Baseline  Airlift  Operation  Model 
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Based  on  the  figures  presented  in  Table  13,  it  can  be  shown  that  the  sorties 
computed  by  the  optimization  model  do  sum  up  to  the  number  generated  by  the  baseline 
airlift  model  and  hence,  verify  the  validity  of  its  simulation  outcome. 

In  the  course  of  verification,  data  refinement  was  found  to  be  necessary  in  order 
to  overcome  rounding  errors  caused  by  various  sources  (e.g.,  documented  data,  software 
tools,  etc.)  that  could  result  in  a  very  different  outcome.  For  example,  based  on  the  7.65 
effective  operating  hours  for  the  day  and  the  round-trip  time  for  CH-53  to  transfer  cargo 
and  equipment  under  the  mean  severity  scenario  (i.e.,  0.51  hr.),  a  direct  calculation  will 
show  that  the  aircraft  can  complete  15  sorties  per  day.  However,  using  the  0.51  hr.  as  an 
input  to  the  airlift  model  in  the  NetBean  IDE,  the  model  would  suggest  that  the  aircraft 
can  only  perform  14  sorties  for  the  day.  By  decreasing  the  round-trip  time  value  in  the 
order  of  10'^,  the  model  will  generate  the  “correct”  answer  of  15  sorties. 

4.  Summary 

Table  14  summarizes  the  force  structure  capabilities  suggested  by  the  baseline 
airlift  model  as  well  as  that  stated  in  the  Project  SEA- 15  report,  both  using  the  same  input 
parameters.  The  presented  figures  for  the  airlift  model  are  strictly  based  on  the  input 
parameters  described  in  this  chapter,  which  are  related  to  the  aircraft  used  for  the  airlift 
operation  and  not  for  the  ships  involved.  For  example,  the  model  suggested  that  the 
cargo  transfer  capability  is  2,286,000  lbs  for  the  low  severity  scenario  but  the  ships  may 
not  necessarily  have  the  storage  space  or  logistics  crew  to  handle  that  load. 
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S/N 

Scenario 

Scenario  Severity 

Low 

Mean 

High 

A. 

Load  Transfer  Capability  based  on  Project  SEA-15  Report  [1] 

19. 

For  Cargo  (lbs) 

1,300,000 

(314%) 

855,000 

(103%) 

1,377,000 

(111%) 

20. 

For  Equipment  (sets) 

6  (100%) 

11  (100%) 

16  (100%) 

21. 

For  Personnel  (pax) 

32  (100%) 

72  (100%) 

99  (100%) 

B. 

Load  Transfer  Capability  based  on  Baseline  Airlift  Model 

22. 

For  Cargo  (lbs) 

2,286,000 

(522%) 

729,000 

(85%) 

1,318,500 

(106%) 

23. 

For  Equipment  (sets) 

6  (100%) 

11  (100%) 

16  (100%) 

24. 

For  Personnel  (pax) 

32  (100%) 

72  (100%) 

99  (100%) 

B. 

Aircraft  Quantity  (i.e.,  the  force  structure) 

25. 

For  CH-53  (ea) 

1 

2 

7 

26. 

For  SH-60  (ea) 

2 

2 

2 

Table  14.  Test  Results  Comparison  for  Baseline  Airlift  Operation  Model 


Based  on  the  verified  airlift  model  results,  the  force  structure  does  not  meet  the 
airlift  requirement  for  the  mean  severity  scenario.  In  order  to  satisfy  the  825,900  lbs  and 
the  other  two  load  type  transfer  requirements,  the  airlift  model  suggested  that  another 
CH-53  aircraft  would  be  required,  increasing  the  force  structure  to  a  three  CH-53  and  two 
SH-60  configuration,  which  would  create  excess  capacity  with  an  enhanced  cargo 
transfer  capability  of  1,13M  lbs  (137%).  Figure  13  depicts  the  simulation  results  for  the 
suggested  force  structure  using  the  load  transfer  capabilities  as  input  for  the  load  transfer 
requirements. 
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Simulation  duration  set:  7.65  hours 

CH-53 

SH-60 

Total 

Number  of  platforms  deployed  : 

3 

2 

5 

Cargo  transferred  (in  lbs)  : 

1053000 

81000 

1134000  (100%) 

Equipment  transferred  (in  sets)  : 

11 

N.A. 

11  (100%) 

Passengers  transferred  (in  pax)  : 

0 

72 

72  (100%) 

Sorties  flown  : 

45 

24 

69 

Average  Utilization  : 

99.96% 

94.59% 

97.27% 

Number  of  cargo  left  : 

Olbs 

Number  of  equipment  left  : 

0  sets 

Number  of  passengers  left  : 

0  pax 

All  loads  have  been  transferred. 

Time  last  sortie  completed  delivery  : 

7.65  hours 

Figure  13.  Revised  Foree  Strueture  Capability  for  Mean  Severity  Scenario  Using 

Baseline  Airlift  Operation  Model 
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IV.  FINAL  AIRLIFT  OPERATION  MODEL 


A.  DESIGN 

1.  Modeling  Approach 

The  baseline  model  encapsulated  the  whole  airlift  operation  as  a  single  process 
with  only  three  essential  events,  i.e.,  load  arrival,  start  and  end  delivery.  This  level  of 
abstraction  limits  the  analysis  to  only  those  basic  performance  measures  as  shown  in 
Chapter  III.  In  order  to  support  operational/  tactical  level  analysis  to  answer  questions 
such  as  the  operation  impact  due  to  unavailability  of  landing  spots,  aircraft  failure,  etc., 
the  airlift  operation  needs  to  be  modeled  in  greater  depth. 

The  final  model  mimics  the  airlift  operation  by  abstracting  the  process  into  six 
main  phases  with  a  central  management  system  responsible  for  planning  and  coordinating 
the  involving  activities  as  described  in  Chapter  II.  Figure  14  illustrates  the  broad-level 
modeling  approach  for  the  airlift  operation  workflow. 
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The  modeled  task  force  was  based  on  the  final  force  structure  recommended  by 
Project  SEA- 15  comprising  three  ships,  namely  JMSDF,  LPD-17  and  JHSV,  and  nine 
aircraft,  i.e.,  seven  CH-53s  and  two  SH-60s.  The  RQ-8  and  Visby  were  excluded 
because  they  do  not  play  a  direct  role  in  the  airlift  operation.  Each  ship  is  a  unique  entity 
having  its  own  set  of  landing  spots  and  logistics  (or  ground)  crew  to  support  the  airlift 
operation  with  an  allocated  quantity  of  loads  to  be  transferred.  In  this  case,  there  are 
three  load  types  to  be  transferred;  cargo,  equipment  and  passengers,  as  defined  in  Project 
SEA- 15.  Each  set  of  logistics  crew  is  assumed  to  be  an  independent  group  that  is  capable 
of  performing  all  the  subtasks  involved  in  preparing  the  load  and  for  the  load-up. 

In  terms  of  the  workflow,  all  loads  will  first  go  through  the  preparation  phase  to 
be  transferred  from  the  holding  area  to  the  landing  spot  and  set  up  for  loading  by  the 
logistics  crew.  When  the  load  is  ready,  the  assigned  aircraft  (if  available)  will  be  called 
in  for  the  load-up,  again  supported  by  the  logistics  crew.  Once  loaded  up,  the  aircraft 
will  commence  the  delivery  sortie  and  the  logistics  crew  and  landing  spots  will  be  freed 
up  to  prepare  for  another  loading.  The  aircraft  will  unload  upon  reaching  the  designated 
target  site  and  recover  back  to  the  ship  after  that.  If  the  aircraft  is  still  in  serviceable 
state,  i.e.,  not  requiring  refueling  or  repair  work,  it  will  continue  with  the  next  airlift 
assignment.  Otherwise,  it  will  seek  service  support  first,  before  continuing  with  the  next 
assignment,  in  which  case,  a  landing  spot  would  be  required  for  each  aircraft  servicing 
operation.  For  each  of  these  six  phases,  there  is  an  associated  variable  “service  time”  to 
perform  the  tasks  involved,  based  on  a  mean  value  with  a  distribution  function.  The 
cycle  will  repeat  itself  for  the  whole  mission  duration  until  all  the  loads  have  been 
transferred. 

In  essence,  the  logistics  crew,  landing  spots  and  aircraft  are  direct  resources 
supporting  the  airlift  operation  with  the  ships  serving  as  depots  to  supply  the  load  and 
provide  facilities  (other  than  landing  spots)  for  the  service  support,  e.g.,  fueling  system, 
maintenance  crew,  etc.,  which  are  not  explicitly  modeled.  The  aircraft,  however,  can 
become  a  constraint  to  the  operation  at  times,  such  as  when  they  require  service  support, 
which  then  draws  landing  spots  away  from  supporting  the  airlift  operation. 
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Table  15  summarizes  the  parameters  modeled  for  the  baseline  and  final  airlift 
operation  models. 


S/N 

Parameters 

Baseline  Model 

Final  Model 

1. 

Aircraft  airlift 
capacity 

Specific  to 

oad  types 

2. 

Aircraft  airlift 
capability 

Specific  to  load  types 

3. 

Load-to-aircraft 

assignment 

Based  on  relative  advantage  using  capacity  ratio 

4. 

Preparation  time 

All  loads  assumes  ready  for 
airlift  at  mission  start  time 

Independent  stochastic  time 
factor 

5. 

Loading  time 

Treated  as  single  round-trip 
process  with  deterministic  time 
factor 

Independent  stochastic  time 
factor 

6. 

Unloading  time 

Independent  stochastic  time 
factor 

7. 

Aircraft  delivery 
time 

Independent  stochastic  time 
factor 

8. 

Aircraft  recovery 
time 

Independent  stochastic  time 
factor 

9. 

Aircraft  refueling 
time 

Block  reduction  on  the  daily 
operating  hours  (deterministic) 

Independent  stochastic  time 
factor 

10. 

Aircraft  time-to- 
failure 

Based  on  Ao  on  the  reduced 
operating  hours  (deterministic) 

Independent  stochastic  time 
factor 

11. 

Aircraft  time-to- 
repair 

Independent  stochastic  time 
factor 

12. 

Aircraft 

Individua 

entities 

13. 

Ships 

Treated  as  single  entity 

Individual  entities 

14. 

Landing  spots  on 
ship 

Unlimited 

Finite  and  ship-specific 

15. 

Logistics  crew  on 
ship 

Unlimited 

Finite  and  ship-specific 

Table  15.  Parameters  Modeled  for  the  Baseline  and  Final  Airlift  Models 


49 


2.  Broad  Level  Design 

There  is  a  radical  change  in  the  design  between  the  baseline  and  the  final  model, 
i.e.,  switching  from  a  “load  arrival”  to  a  “landing  spot  arrival”  triggered  process.  This 
switch  is  primarily  to  enable  the  “central  management  system”  to  plan  ahead  for  the  load 
type  and  the  quantity  that  a  landing  spot  needs  to  prepare,  based  on  the  next  anticipated 
aircraft  that  will  be  available  for  the  load-up. 

The  design  for  the  operation  process  is  best  described  using  a  flow  chart,  which  is 
depicted  in  Figure  15  and  summarized  as  follows: 

•  The  simulation  commences  with  the  creation  of  resources  (aircraft,  ships, 
logistics  crew  and  landing  spots)  and  allocation  of  loads  to  the  various 
ships  based  on  user  inputs.  This  is  followed  by  a  check  to  identify  any 
failed  aircraft  (i.e.,  aircraft  that  has  encountered  failure),  which  will  be 
transferred  to  the  “Need  Support  List.” 

•  A  landing  spot  from  each  ship  will  be  triggered  next  and  removed  from  the 
available  list  to  check  for  a  new  task,  and  to  find  out  whether  there  are 
aircraft  requiring  service  support  (refuel  and/or  repair)  and  if  so,  whether 
there  are  enough  landing  spots  already  set  aside  to  support  them  (in  the 
“Support  LS  list,”  which  is  empty  at  this  point).  The  consideration  for  the 
number  of  landing  spots  is  further  discussed  under  the  Support  Landing 
Spot  Allocation  subsection.  If,  indeed,  a  landing  spot  is  required,  it  will 
then  check  whether  there  is  already  an  aircraft  waiting  for  the  service 
support  and  if  so,  to  commence  the  service  or  otherwise,  it  will  be  added  to 
the  “Support  LS  list”  to  standby  for  the  aircraft. 

•  If  the  landing  spot  is  not  required  for  service  support,  it  will  next  check  for 
an  available  logistics  crew,  remaining  load  left  for  transfer,  and  unassigned 
aircraft,  which  there  will  be  for  all  of  them  at  this  juncture.  In  the  event 
that  any  of  these  is  not  available,  which  will  happen  as  the  mission 
proceeds,  the  landing  spot  will  be  reinserted  back  to  the  available  list  and 
wait  for  the  next  trigger  event  to  occur. 
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Figure  15.  Flow  Chart  for  Final  Airlift  Operation  Model 
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•  Based  on  some  preset  criteria,  which  is  further  discussed  under  the  Load 
Allocation  subsection,  an  assignment  will  be  issued,  specifying  the 
assigned  aircraft,  load  type  and  the  quantity  that  the  landing  spot  needs  to 
prepare  for.  The  landing  spot  will  then  proceed  with  load  preparation  and 
use  a  set  of  logistics  crew  to  support  it. 

•  Upon  completion  of  the  load  preparation,  the  landing  spot  will  check 
whether  the  assigned  aircraft  is  ready.  If  the  aircraft  is  ready,  loading  will 
commence,  and  once  completed,  the  aircraft  will  begin  its  delivery  sortie 
and  the  landing  spot  will  restart  the  “check  task”  process.  As  for  the 
relieved  crew,  it  will  first  check  whether  there  is  a  landing  spot  with  its 
assigned  aircraft  ready  and  waiting  for  loading  (the  priority  pair)  and  if 
there  is,  loading  will  commence  for  that  pair.  Otherwise,  the  “check  task” 
event  will  be  triggered  if  there  are  other  available  landing  spots  and  the 
crew  will  just  stand  by  for  the  next  assignment. 

•  If  the  aircraft  is  unavailable,  the  logistic  crew  will  be  relieved  to  support 
another  assignment  and  will  perform  the  checks  described  earlier.  As  for 
the  landing  spot,  it  will  stand  by  and  wait  for  the  assigned  aircraft  to  be 
ready  unless  the  aircraft  has  encountered  failure.  Under  such 
circumstances,  the  landing  spot  will  either  “return”  the  load  to  the  holding 
space  and  restart  the  “check  task”  process,  or  request  another  unassigned 
aircraft  to  “take  over”  the  prepared  load.  The  decision  will  depend  on  the 
reassignment  scheme  used  for  that  simulation  run,  which  is  further 
discussed  under  the  Landing  Spot  Reassignment  subsection. 

•  As  the  aircraft  commences  the  delivery  sortie,  it  will  also  put  in  a  request 
for  the  next  assignment  (by  adding  the  aircraft  to  the  Holding  A/C  list). 
The  aircraft  will  provide  the  expected  return  time  to  allow  for  the 
assignment  detailing,  taking  into  consideration  the  (mean)  refueling  time  if 
it  requires  a  refuel  upon  return  to  ship. 
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•  The  aircraft  will  next  reach  the  target  site  and  unload,  following  which  it 
will  return  to  ship.  Should  the  aircraft  fail  anytime  between  the  loading 
and  recovery  phase,  it  will  continue  and  complete  the  assignment  on  the 
assumption  that  the  failure  is  not  catastrophic,  which  would  warrant  an 
alternative  action  to  be  taken  immediately.  An  aircraft  failure  would  be 
made  known  instantly  to  trigger  any  available  landing  spot  to  start  the 
“check  task”  process.  If  the  aircraft  has  put  in  a  request  for  a  next 
assignment  and  had  not  been  given  one  yet,  the  request  will  be  withdrawn. 
Otherwise,  the  assigned  landing  spot  will  request  either  a  new  task  or  a 
replacement  aircraft,  as  described  earlier. 

•  Upon  returning  to  ship,  the  aircraft  will  check  whether  it  needs  service 
support.  If  it  does,  and  there  are  landing  spots  reserved  to  support  that,  the 
service  will  commence.  Otherwise,  the  aircraft  will  have  to  wait  and  be 
added  to  the  Waiting  A/C  List. 

•  If  service  support  is  not  required  and  the  aircraft  has  a  next  assignment 
with  the  assigned  landing  spot  and  logistics  crew  available,  loading  will 
commence  and  the  follow-on  process  is  as  described  earlier.  If  the  aircraft 
has  not  been  assigned,  or  any  of  the  required  resources  are  not  available, 
the  aircraft  will  be  added  to  appropriate  list  and  wait  for  the  next  trigger. 
Should  the  aircraft  have  failed  while  waiting,  it  will  be  transferred  to  the 
“Need  Support  List”  to  seek  support. 

(a)  Support  Landing  Spot  Allocation 

The  number  of  landing  spots  that  can  be  set  aside  for  service  support  was 
designed  to  be  user-input  controllable  using  two  parameters,  except  under  a  special 
condition.  The  first  parameter  is  the  minimum  number  of  landing  spots  each  ship  must 
have  at  any  one  time  to  cater  to  activities  directly  related  to  the  airlift  operation,  i.e.,  the 
preparation  and  loading  events.  In  other  words,  the  difference  between  this  number  and 
the  total  number  of  landing  spots  is  the  maximum  allowable  support  landing  spots  a  ship 


53 


can  set  aside  to  provide  service  support.  The  second  parameter  is  the  maximum 
allowable  support  landing  spots  that  the  whole  fleet  (of  three  ships)  can  set  aside  to 
provide  service  support,  which  forms  the  ceiling  regardless  of  whether  the  individual 
ships  have  reached  their  respective  quota. 

This  “maximum  rule”  will  apply  for  each  ship  under  all  conditions  except 
when  it  has  completed  all  the  load  transfers,  which  in  this  case  makes  sense  to  open  up 
the  landing  spots  to  provide  service  support,  since  they  will  not  be  utilized  otherwise. 

(b)  Load  Allocation 

The  model  has  incorporated  two  user-selectable  schemes  to  manage  the 
load  allocation  for  the  airlift  assignment.  As  highlighted  under  the  baseline  model  design 
in  Chapter  III,  the  load-to-aircraft  assignment  is  driven  by  the  aircraft’s  relative  transfer 
advantage  based  on  its  capacity  ratio  in  order  to  optimize  the  aircraft  usage,  and  the  same 
logic  is  inherited  in  this  final  model. 

The  first  scheme  adopts  a  micro  management  approach  whereby  the 
allocation  of  load  is  optimized  at  the  ship-level  only.  In  other  words,  the  model  will  only 
check  for  the  remaining  load  onboard  the  ship  and  determine  the  optimal  load  type  that 
the  landing  spot  should  prepare  for  the  next  anticipated  aircraft  that  will  be  available.  For 
example,  if  the  next  available  aircraft  is  a  SH-60,  which  has  the  relative  advantage  of 
transporting  passengers,  passengers  would  be  assigned  to  the  landing  spot  if  it  is  among 
the  load  types  remaining  onboard  the  associated  ship.  Otherwise,  the  landing  spot  will  be 
assigned  the  next  optimal  load  that  is  onboard  the  ship  for  the  SH-60;  the  model  will  not 
consider  holding  off  the  aircraft  for  another  ship  that  still  has  passengers  onboard. 

The  second  scheme,  on  the  other  hand,  will  do  that  in  an  attempt  to 
optimize  the  load  allocation  at  the  fleet-level.  The  general  concept  is  to  get  the  next 
available  aircraft  for  both  aircraft  types  and,  based  on  their  expected  available  time 
difference  and  the  remaining  load  in  the  fleet  to  determine  the  load  type  and  aircraft  for 
the  assignment.  The  model  does  so  by  performing  the  following: 
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•  With  a  landing  spot  request  for  a  new  assignment,  the  model  will  eheck  for 
the  next  available  aireraft  in  the  holding  list  for  both  the  aircraft  types  (i.e., 
CH-53  and  SH-60).  If  there  is  only  one  aircraft  type  on  the  list,  or  the 
optimal  load  type  is  available  onboard  the  ship  for  the  aircraft  type  with  an 
earlier  expected  available  time,  the  model  will  assign  the  load  type  and 
aircraft  to  the  landing  as  per  the  first  scheme. 

•  Otherwise,  the  model  will  compute  the  expected  available  time  difference 
for  the  aircraft  and  compare  it  to  a  user-defined  threshold  value.  This 
threshold  value  is  essentially  the  wait  time  that  the  user  is  willing  to  accept 
in  order  to  have  the  “more  suited”  aircraft  pick  up  the  remaining  load 
onboard  that  ship.  If  the  time  difference  exceeds  this  threshold  value,  the 
model  will  proceed  to  assign  the  load  for  first  available  aircraft  as  per  the 
first  scheme.  For  example,  if  the  threshold  value  is  five  minutes  and  a 
CH-53  is  expected  to  be  available  seven  minutes  before  the  next  SH-60, 
the  model  will  assign  passengers  to  the  CH-53  if  it  is  the  only  load  type 
left  onboard  the  ship,  even  though  the  optimal  load  type  (equipment)  for 
the  CH-53  may  be  available  onboard  the  other  ships,  and  the  SH-60  is  in 
the  holding  list  waiting  for  its  assignment. 

•  However,  if  the  time  difference  is  within  the  threshold  value,  and  the 
optimal  load  type  for  the  earlier  available  aircraft  can  be  found  onboard 
the  other  ships,  the  model  will  assign  the  later  available  aircraft  and  its 
optimal  load  type  to  the  landing  spot  instead.  For  the  cited  example,  the 
model  would  have  assigned  the  SH-60  and  passengers  as  the  load  type  to 
the  landing  spot,  and  hold  off  the  CH-53  for  a  later  assignment. 

•  In  the  event  where  the  optimal  load  type  for  an  aircraft  type  has  been  fully 
transferred,  the  same  logic  applies  for  the  next  optimal  load  type,  and  so 
forth. 
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As  the  study  is  about  a  new  naval  force  structure,  the  two  options  will  at 
least  allow  one  to  analyze  the  impact  of  employing  different  management  schemes  to  the 
said  situation. 


( c)  Landing  Spot  Reassignment 

The  model  has  two  user-selectable  schemes  incorporated  to  handle 
situations  when  a  landing  spot  has  prepared  the  load  but  the  assigned  aircraft  failed 
before  it  could  pick  up  the  load.  For  the  first  scheme  (i.e.,  mode  #0  as  depicted  in  the 
flow  chart  diagram),  which  is  a  substitution  approach,  the  landing  spot  will  find  the  next 
available  replacement  of  the  same  aircraft  type  as  the  failed  aircraft  so  that  the  prepared 
load  can  be  readily  transferrable  to  the  newly  assigned  aircraft.  The  second  scheme  (i.e., 
mode  #1  in  the  flow  chart  diagram)  is  essentially  a  “start  fresh”  approach  whereby  the 
prepared  load  will  be  returned  to  the  holding  space  to  free  up  the  landing  spot  to  check 
for  the  next  task. 

Again,  the  options  are  implemented  to  analyze  the  various  possibilities  of 
handling  the  stated  situations. 

B.  ASSUMPTIONS 

Based  on  the  above-mentioned  design  concept,  the  following  are  the  further 
considerations  and  assumptions  made: 

•  All  ships  have  facilities  to  support  the  refueling  and  repair  for  both  aircraft 
types. 

•  All  ships  are  stationary  and  positioned  at  the  same  distance  from  the 
designated  target  sites. 

•  No  adverse  weather  conditions  that  will  substantially  impact  the  aircraft 
airspeed. 

•  There  are  ample  landing  spots  and  ground  crew  support  at  the  target  sites, 
i.e.,  no  queuing  required  for  unloading. 
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•  The  recovery  of  the  cargo  nets,  pallets,  and  hoisting  slings  used  for  the 
sling  operations  can  be  performed  as  part  of  the  recovery  sortie  after 
transporting  passengers  to  the  target  site  with  no  additional  lead-time. 

C.  IMPLEMENTATION 

The  final  airlift  operation  model  was  implemented  using  simkit,  which  is 
comprised  of  five  unique  components,  namely  Aircraftinitializer,  AircraftServer, 
ShipServer,  Scheduler  and  Recorder.  The  SimEventListener  structure  for  the  mode  is 
depicted  in  Figure  16. 


Figure  16.  SimEventListener  Structure  for  Final  Airlift  Operation  Model 
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The  parameters  and  state  variables  for  the  model  are  listed  in  the  next  two  tables 
with  the  SimEntity  objects  and  the  model  components  described  in  the  follow-on 
subsections: 


S/N 

Field 

Parameters 

1. 

ai 

Ship  entity  with  identifier  i,  i.e.,  i  =  0,  1  and  2  for  JMSDF,  LPD-17  and 
JHSV  respectively. 

data  type:  int 

2. 

bi 

Landing  spot  entity  for  ship  entity  with  identifier  i. 

data  type:  LandingSpot 

3. 

Ck 

Aircraft  entity  of  type  k,  i.e.,  k  =  0  and  1  for  CH-53  and  SH-60 
respectively. 

data  type:  int 

4. 

m 

Total  number  of  ships. 

data  type:  int 

5. 

Hi 

Total  number  of  landing  spots  for  ship  entity  with  identifier  i. 

data  type:  int  for  ShipServer  and  intfj  for  Scheduler 

6. 

nLi 

Minimum  number  of  landing  spots  that  must  be  available  at  any  one  time 
for  direct  airlift  operation  support  (i.e.,  for  load  preparation  and  loading 
activities  only)  for  ship  entity  with  identifier  i. 

data  type:  int 

7. 

ns 

Maximum  number  of  landing  spots  for  the  whole  fleet  that  can  be  set  aside 
for  support  services  (refuel  and  repair).  This  is  herein  referred  to  as 
maximum  number  support  landing  spots 

data  type:  int 

8. 

Yi 

Total  number  of  logistics  crew  for  ship  entity  with  identifier  i. 

data  type:  int 

9. 

qiii] 

Quantity  allocated  to  ship  entity  with  identifier  i  for  load  type  1,  i.e.,  1  =  0, 
1,  2  for  cargo  (in  lbs),  equipment  (in  sets)  and  passengers  (in  pax) 
respectively. 

data  type:  int[] 

10. 

qT[ii 

Total  load  quantity  to  be  transferred  for  load  type  1,  i.e.,  1  =  0,  1,  2  for 
cargo  (in  lbs),  equipment  (in  sets)  and  passengers  (in  pax)  respectively. 
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data  type:  int[] 

11. 

Pk 

Total  number  of  aircraft  of  type  k. 

data  type:  int 

12. 

Ski 

Transfer  capacity  for  aircraft  of  type  k  for  load  type  1. 

data  type:  int 

13. 

tl 

Time  interval  for  recording  the  load  quantity  delivered  over  the  mission 
time  (simulation  duration). 

data  type:  double 

14. 

tpikiji 

Sequence  of  possibly  random  service  times  to  perform  load  preparation  of 
load  type  j  by  ship  with  identifier  i  for  aircraft  type  k. 

data  type:  simkit.random.RandomVariate[] 

15. 

tkikUi 

Sequence  of  possibly  random  service  times  to  perform  loading  for  load 
type  j  by  ship  with  identifier  i  for  aircraft  type  k. 

data  type:  simkit.random.RandomVariatefJ 

16. 

tokij] 

Sequence  of  possibly  random  sortie  times  to  deliver  load  type  j  from  ship 
to  target  site  for  aircraft  type  k. 

data  type:  simkit.random.RandomVariate[] 

17. 

tRkIj] 

Sequence  of  possibly  random  sortie  times  to  recover  from  target  site  to 
ship  after  unloading  load  type  j  for  aircraft  type  k. 

data  type:  simkit.random.RandomVariate[] 

18. 

tuklj] 

Sequence  of  possibly  random  service  times  to  unload  load  type  j  at  target 
site  for  aircraft  type  k. 

data  type:  simkit.random.RandomVariatefJ 

19. 

tRFk 

Sequence  of  possibly  random  service  times  to  refuel  aircraft  type  k. 

data  type:  simkit.random.RandomVariate 

20. 

tRPk 

Sequence  of  possibly  random  service  times  to  repair  aircraft  type  k. 

data  type:  simkit.random.RandomVariate 

21. 

tpk 

Sequence  of  possibly  random  time-to-failure  for  aircraft  type  k. 

data  type:  simkit.random.RandomVariate 

22. 

tw 

Expected  arrival  time  difference  that  a  ship  is  wiling  to  wait  in  order  to  get 
a  better  aircraft  match  (optimized)  for  the  remaining  load  onboard  the  ship, 
based  on  the  unassigned  aircraft  in  the  holding  list.  This  parameter  is  only 
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applicable  under  Allocation  Mode  #1  scheme. 

data  type:  double 

Table  16.  Parameters  for  Final  Airlift  Operation  Model 


S/N 

Field 

State  Variables 

1. 

Ah 

List  of  assignments  that  have  been  issued  for  the  airlift  operation  with  the 
details  on  the  involved  landing  spot,  aircraft,  amount  and  type  of  load 
transferred,  timing  for  various  phases,  etc. 

data  type:  java. util.LinkedList<Item> 

2. 

Ah 

List  of  sorted  aircraft  of  all  types  based  on  their  expected  time  available  for 
next  assignment;  initial  value  is  0.  The  list  is  used  by  the  Scheduler  for 
detailing  assignments  and  is  herein  referred  to  as  the  aircraft  holding  list. 

data  type:  :  java.util.LinkedList<Aircraft> 

3. 

Arr 

List  of  ready  aircraft  of  type  k  with  new  assignment  but  its  assigned 
landing  spot  is  unavailable  yet;  initial  value  is  0.  The  list  is  herein  referred 
to  as  the  ready  aircraft  list. 

data  type:  java. util.LinkedList<Aircraft> 

4. 

Apk 

List  of  aircraft  of  type  k  with  new  assignment  but  it  is  not  ready  yet;  initial 
value  is  0.  The  list  is  herein  referred  to  as  the  planned  aircraft  list. 

data  type:  java. util.LinkedList<Aircraft> 

5. 

As 

List  of  aircraft  requiring  support  service  (refuel  and/or  repair)  that  has  not 
been  allocated  a  support  landing  spot  yet;  initial  value  is  0. 

data  type:  java. util.LinkedList<Aircraft> 

6. 

Aw 

List  of  aircraft  requiring  support  service  that  has  returned  to  ship  and  is 
waiting  for  an  available  support  landing  spot,  which  may  or  may  not  have 
been  allocated  one;  initial  value  is  0. 

data  type:  java. util.LinkedList<Aircraft> 

7. 

Ci 

Number  of  available  logistics  crew  for  ship  entity  with  identifier  i;  initial 
value  is  total  number  of  logistics  crew  for  that  ship  (n). 

data  type:  int 

8. 

Dili 

Quantity  delivered  to  site  for  load  type  1;  initial  value  is  0. 

data  type:  int[] 
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9. 

Dk|i] 

Quantity  delivered  to  site  by  aircraft  type  k  for  load  type  1;  initial  value  is 
0. 

data  type:  int[] 

10. 

D|i|[t] 

Quantity  delivered  to  site  for  load  type  1  at  time  interval  t;  initial  value  is  0. 

data  type:  int[] [] 

11. 

Fk 

Number  of  airlift  sorties  flown  by  aircraft  type  k;  initial  value  is  0. 

data  type:  int 

12. 

Lai 

List  of  available  landing  spots  for  ship  entity  with  identifier  1;  initial  value 
is  total  number  of  landing  spots  for  that  ship  (ni). 

data  type:  java.  util.LinkedList<LandingSpot> 

13. 

H 

List  of  records  on  the  timing  when  an  aircraft  has  made  a  request  for 
new/next  assignment  and  when  it  is  given  one  or  it  has  retracted  the 
request  to  due  to  aircraft  failure. 

data  type:  java.  util.LinkedList<Entry> 

14. 

Ic 

Indicator  for  the  delivery  completion  for  all  load  type,  i.e.,  0  and  1  for 
incomplete  and  complete  respectively;  initial  value  is  0. 

data  type:  int 

15. 

Lai 

List  of  available  landing  spots  for  ship  with  identifier  i;  initial  value  is  null. 

data  type:  java.  util.LinkedList<LandingSpot> 

16. 

Lu 

List  of  landing  spots  with  active  ongoing  activities  (preparing  or  loading) 
directly  related  to  an  assignment  for  s  with  identifier  i;  initial  value  is  null. 
The  list  is  herein  referred  to  as  active  landing  spot  list. 

data  type:  java.  util.LinkedList<LandingSpot> 

17. 

Lpi 

List  of  loaded  landing  spots  with  ready  aircraft  waiting  for  the  next  set  of 
available  logistics  crew  to  perform  loading  for  ship  entity  with  identifier  i; 
initial  value  is  null.  The  list  is  herein  referred  to  as  the  priority  list. 

data  type:  java.  util.LinkedList<LandingSpot> 

18. 

Lr 

List  of  landing  spots  requiring  a  replacement  aircraft  to  take  over  the  load 
prepared  for  an  earlier  assigned  aircraft  that  has  failed  for  ship  with 
identifier  I;  initial  value  is  null.  This  variable  is  only  applicable  under  the 
Replacement  Mode  #0  scheme. 

data  type:  java.util.LinkedList<  LandingSpot  > 

19. 

Ls 

List  of  landing  spots  reserved  to  perform  support  services  for  the  whole 
fleet;  initial  value  is  null.  The  list  is  herein  referred  to  as  support  landing 
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spot  list. 

data  type:  java.  util.LinkedList<LandingSpot> 

20. 

Lwi 

List  of  loaded  landing  spots  for  ship  with  identifier  i  waiting  for  aircraft 
arrival  to  perform  next  load-up  for  ship  entity  with  identifier  1;  initial  value 
is  null.  The  list  is  herein  referred  to  as  standby  landing  spot  list. 

data  type:  java.  util.LinkedList<LandingSpot> 

21. 

NAk 

Number  of  available  aircraft  of  type  k;  initial  value  is  0. 

22. 

Nar 

Number  of  aircraft  of  type  k  in  process  of  loading  up;  initial  value  is  0. 

23. 

Nok 

Number  of  aircraft  of  type  k  in  process  of  delivering  load  from  ship  to 
target  site;  initial  value  is  0. 

24. 

Nuk 

Number  of  aircraft  of  type  k  in  process  of  unloading  at  target  site;  initial 
value  is  0. 

25. 

Nrr 

Number  of  aircraft  of  type  k  in  process  of  recovering  from  target  site  to 
ship;  initial  value  is  0. 

26. 

Nrfr 

Number  of  aircraft  of  type  k  in  process  of  refueling;  initial  value  is  0. 

27. 

Nrpr 

Number  of  aircraft  of  type  k  undergoing  repair;  initial  value  is  0. 

28. 

Nwk 

Number  of  aircraft  of  type  k  waiting  for  load-up  or  support  service;  initial 
value  is  0. 

29. 

Nai 

Number  of  available  landing  spots  for  ship  with  identifier  i;  initial  value  is 
0. 

data  type:  int 

30. 

Nli 

Number  of  landing  spots  with  active  ongoing  activities  (preparing  or 
loading)  directly  related  to  an  assignment  for  ship  with  identifier  i;  initial 
value  is  0. 

data  type:  int 

31. 

Nsi 

Number  of  landing  spots  reserved  to  perform  support  services  for  ship 
entity  with  identifier  i;  initial  value  is  0. 

data  type:  int 

32. 

Nwi 

Number  of  standby  landing  spots  awaiting  for  aircraft  arrival  to  perform 
next  load-up  for  ship  entity  with  identifier  i;  initial  value  is  0. 

data  type:  int 

33. 

Qi[l| 

Remaining  quantity  of  load  type  1  for  ship  entity  with  identifier  i;  initial 
value  is  the  total  quantity  of  that  load  type  allocated  to  the  ship  (qi[i|). 
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data  type:  int[]  for  ShipServer  and  int[] []  for  Scheduler 

34. 

Qin 

Remaining  quantity  of  load  type  1  for  the  whole  fleet;  initial  value  is  the 
sum  of  total  quantity  of  that  load  type  allocated  to  each  ship. 

data  type:  int[] 

35. 

Qtii] 

Total  quantity  of  load  type  1;  initial  value  is  0. 

data  type:  int[] 

36. 

Tc 

The  completion  time  when  all  load  types  have  been  transferred  to  target 
site;  initial  value  is  0. 

data  type:  double 

Table  17.  State  Variables  for  Final  Airlift  Operation  Model 


1.  SimEntity  Objects 

There  are  two  categories  of  SimEntity  objects  created  to  support  the  simulation. 
The  first  category  is  used  to  model  the  real-world  physical  entities,  i.e.,  aircraft,  ship  and 
landing  spot.  The  second  category  is  generated  for  keeping  track  of  simulation  data  to 
support  the  simulation  as  well  as  for  post-simulation  review. 

(a)  Aircraft  SimEntity 

The  Aircraft  SimEntity  is  a  generic  object  that  models  both  the  CH-53  and 
SH-60  aircraft  types;  the  parameters  defined  for  the  object  differentiate  them.  An 
Aircraft  object  is  instantiated  for  each  aircraft  entity  simulated  in  the  scenario.  The 
attributes  defined  for  this  object  class  are  described  in  the  following  table. 
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A. 

Parameter 

1. 

id 

Identifier  for  the  aircraft  entity. 

data  type:  int 

2. 

type 

Platform  type  for  the  aircraft  entity,  i.e.,  CH53  or  SH60. 

data  type:  String 

3. 

capacity 

Transfer  capacity  for  different  load  types  for  the  aircraft 
entity.  There  are  currently  three  different  load  types  that  the 
model  is  designed  for,  i.e.,  cargo,  equipment  and 
passengers,  and  an  array  (of  three  elements)  is  used  to  store 
the  values  in  that  sequence. 

data  type:  int[] 

4. 

speed 

Speed  transiting  between  ship  and  target  site  for  the  aircraft 
entity.  As  the  aircraft  may  travel  slower  when  carrying 
load,  especially  during  sling  load  operations,  different 
speeds  will  need  to  be  defined  for  the  delivery  and  recovery 
phase. 

There  are  currently  three  different  load  types  that  the  model 
is  designed  for,  i.e.,  cargo,  equipment  and  passengers,  and  a 
3x2  dimensional  array  is  used  to  store  the  values  with  the 
row  designated  for  the  load  type  in  the  same  sequence.  The 
first  column  is  meant  for  the  delivery  speed  and  the  second 
for  recovery  speed. 

data  type:  int[] [] 

5. 

meanHookOffr  ime 

The  meantime  to  hook-off  (unload)  the  load  from  the 
aircraft  entity.  There  are  currently  three  different  load  types 
that  the  model  is  designed  for,  i.e.,  cargo,  equipment  and 
passengers,  and  an  array  (of  three  elements)  is  used  to  store 
the  values  in  that  sequence. 

data  type:  double[] 

6. 

minBufferTime 

Minimum  buffer  time  that  an  aircraft  must  be  able  to  hold  in 
the  air  upon  returning  to  ship  in  case  there  is  no  available 
landing  spot  for  landing.  The  parameter  is  used  for 
refueling  considerations. 

data  type:  double 
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7. 

minBufferF  actor 

Minimum  buffer  factor  based  on  the  travel  distanee  between 
the  ship  and  target  site  that  an  aireraft  must  eater  for  a  sortie 
for  refueling  considerations.  (For  example,  a  factor  of  0.1 
for  a  ship  and  the  target  area  that  are  50  nm  apart  means  that 
the  aireraft  will  only  carry  out  the  sortie  if  it  has  enough  fuel 
to  eover  at  least  110  nm.) 

data  type:  double 

8. 

maxDistance 

The  maximum  distanee  that  the  aireraft  entity  can  travel  in 
between  refuels. 

data  type:  double 

B. 

State  Variable 

9. 

needRepair 

A  state  for  the  aircraft  entity  to  indieate  that  it  needs  repair. 
This  value  is  referenced  by  the  Scheduler  to  allocate  a 
landing  spot  to  support  the  service  task. 

data  type:  boolean 

10. 

needRefuel 

A  state  for  the  aireraft  entity  to  indieate  that  it  needs  to 
refuel.  This  value  is  referenced  by  the  Scheduler  to  alloeate 
a  landing  spot  to  support  the  serviee  task. 

data  type:  boolean 

11. 

distanceTravelled 

The  distanee  travelled  by  the  aircraft  entity  since  the  start  of 
simulation  or  last  refuel,  whiehever  is  the  later  event.  This 
value  is  refereneed  by  the  AireraftServer  instances  to 
determine  when  refueling  is  required. 

data  type:  int 

12. 

expectedRetumX  ime 

The  expected  time  that  the  aireraft  entity  will  return  to  ship, 
complete  the  refuel  (if  required)  and  be  ready  to  exeeute  the 
next  assignment.  This  value  is  referenced  by  the  Scheduler 
for  detailing  assignments. 

data  type:  double 

13. 

assignment 

Assignment  that  the  aireraft  entity  has  been  given  and  is 
currently  being  executed,  i.e.,  from  the  point  loading 
commenees  till  the  aireraft  returns  to  ship  and  is  ready  for 
its  next  assignment  (including  refueling  and  repairing 
work). 

data  type:  Item 

65 


S/N 

Attribute 

Description 

14. 

entry 

Record  of  when  the  aircraft  entity  has  last  requested  an 
assignment  and  time  when  it  was  given  one  or  when  it 
retracted  the  request  due  to  aircraft  failure. 

data  type:  Entry 

15. 

nextLandingSpot 

Landing  spot  that  the  aircraft  is  assigned  to  for  the  new/next 
assignment. 

data  type:  LandingSpot 

16. 

totalSorties 

Total  number  of  sorties  flown  (or  delivery  made)  by  the 
aircraft  entity. 

data  type:  int 

17. 

state 

Enumerator  to  indicate  the  current  phase  that  the  aircraft 
entity  is  in,  that  is,  available  with  no  assignment  (0)  waiting 
to  execute  next  assignment  (1),  loading  up  (2),  delivering 
load  to  target  site  (3),  unloading  (4),  recovering  to  ship  (5), 
refueling  (6),  and  repairing  (7). 

data  type:  int 

18. 

status 

Enumerator  to  indicate  whether  an  aircraft  entity  has  been 
given  a  new/next  assignment,  that  is,  not  assigned  (0)  and 
assigned  (1). 

data  type:  int 

Table  18.  Attributes  for  Aircraft  SimEntity  Object 


(b)  Ship  SimEntity 

The  Ship  SimEntity  is  a  generic  object  that  can  model  any  of  the  ship 
types,  JMSDF,  LED- 17  and  JHSV;  the  parameters  defined  for  the  object  differentiate 
them.  A  Ship  object  is  instantiated  for  each  ship  entity  simulated  in  the  scenario.  The 
attributes  defined  for  this  object  class  is  described  in  the  following  table. 
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A. 

Parameter 

1. 

id 

Identifier  for  the  ship  entity. 

data  type:  int 

2. 

type 

Platform  type  for  the  ship  entity,  i.e.,  JMSDF,  LPD17  or 
JHSV. 

data  type:  String 

3. 

totalLandingSpots 

Total  number  of  landing  spots  for  the  ship  entity. 

data  type:  int 

4. 

totalLogCrew 

Total  number  of  logistics  crew  (set)  on  the  ship  entity. 

data  type:  int 

5. 

landingSpotList 

List  of  landing  spot  entities  for  the  ship  entity. 

data  type:  java.  util.LinkedList<LandingSpot> 

B. 

State  Variable 

6. 

allocatedLoad 

Quantity  for  each  load  type  onboard  the  ship  entity. 

data  type:  int[] 

Table  19.  Attributes  for  Ship  SimEntity  Object 


(c)  LandingSpot  SimEntity 

The  LandingSpot  SimEntity  is  a  generic  object  created  to  model  the 
landing  spots  for  all  the  ships.  A  LandingSpot  object  is  instantiated  for  each  landing  spot 
as  it  needs  to  maintain  its  own  unique  states  at  any  given  time  during  simulation.  The 
attributes  defined  for  this  object  class  is  described  in  the  following  table. 
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A. 

Parameter 

1. 

id 

Identifier  for  the  landing  spot  entity. 

data  type:  int 

2. 

associatedShipId 

Identifier  for  the  ship  entity  that  the  landing  spot  is  associated 
with,  i.e.,  with  value  =  0,  1  and  2  for  JMSDF,  LPD-17  and 
JHSV  respectively. 

data  type:  int 

B. 

State  Variable 

3. 

assignment 

Airlift  assignment  (object)  given  to  the  landing  spot. 

data  type:  Item 

4. 

supportAircraft 

Aircraft  (object)  that  the  landing  spot  is  tasked  to  provide 
support  services  (refuel  and  repair)  to. 

data  type:  Aircraft 

Table  20.  Attributes  for  LandingSpot  SimEntity  Object 


(d)  Item  SimEntity 

The  Item  SimEntity  object  is  created  to  keep  track  of  each  individual 
assignment  data  that  is  used  to  support  the  simulation,  as  well  as  for  post-simulation 
review.  Table  18  describes  the  attributes  defined  for  the  entity. 
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Attribute 

Description 

A. 

Parameter 

1. 

id 

Identifier  for  the  assignment  entity. 

data  type:  int 

B. 

State  Variable 

2. 

assignmentTime 

The  time  when  the  assignment  entity  is  created. 

data  type:  double 

3. 

landingSpot 

The  landing  spot  entity  that  is  assigned  to  this  assignment 
entity. 

data  type:  LandingSpot 
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4. 

aircraft 

The  aircraft  entity  that  is  assigned  to  this  assignment  entity. 

data  type:  Aircraft 

5. 

loadType 

The  load  type  to  be  transferred  under  this  assignment. 

data  type:  int 

6. 

loadQuantity 

The  quantity  of  the  assigned  load  type  to  be  transferred  under 
this  assignment. 

data  type:  int 

7. 

startPrepareT  ime 

The  time  when  the  load  preparation  starts. 

data  type:  double 

8. 

endPrepareTime 

The  time  when  the  load  preparation  ends. 

data  type:  double 

9. 

startLoadingT  ime 

The  time  when  the  loading  starts. 

data  type:  double 

10. 

endLoadingT  ime 

The  time  when  the  loading  ends. 

data  type:  double 

11. 

startSortieTime 

The  time  when  the  assigned  aircraft  starts  the  sortie  (leaves  the 
ship). 

data  type:  double 

12. 

reachT  argetT  ime 

The  time  when  the  assigned  aircraft  reaches  the  target  site  and 
start  unloading. 

data  type:  double 

13. 

leaveTargetTime 

The  time  when  the  assigned  aircraft  completes  unloading  and 
leaves  the  target  site. 

data  type:  double 

14. 

endSortieTime 

The  time  when  the  assigned  aircraft  returns  to  ship. 

data  type:  double 

15. 

startRefuelTime 

The  time  when  the  assigned  aircraft  starts  refueling. 

data  type:  double 

16. 

endRefuelTime 

The  time  when  the  assigned  aircraft  ends  refueling. 

data  type:  double 
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17. 

startRepairTime 

The  time  when  the  repair  work  for  the  assigned  aircraft  starts. 

data  type:  double 

18. 

endRepairTime 

The  time  when  the  repair  work  for  the  assigned  aircraft  starts. 

data  type:  double 

19. 

readyTime 

The  time  when  the  assigned  aircraft  is  ready  to  execute  its  next 
assignment,  which  marks  the  end  of  this  assignment. 

data  type:  double 

20. 

expectedDuration 

The  expected  sortie  duration,  i.e.,  the  time  between  when  the 
assigned  aircraft  starts  and  ends  a  sortie.  This  duration  is 
computed  based  on  the  sum  of  the  travel  time  to  and  from  the 
target  site  (dividing  distance  by  speed),  the  mean  time  to 
unload  and  mean  time  to  refuel  (if  the  aircraft  needs  to  be 
refueled  upon  return  to  ship  for  this  assignment). 

data  type:  double 

21. 

actualDuration 

The  actual  sortie  duration,  i.e.,  the  measured  time  between 
when  the  assigned  aircraft  starts  and  ends  a  sortie. 

data  type:  double 

22. 

remainingLoad 

The  remaining  quantity  for  all  load  types  left  to  be  transferred, 
after  discounting  the  quantity  to  be  transferred  under  this 
assignment.  There  are  currently  three  different  load  types  that 
the  model  is  designed  for,  cargo,  equipment  and  passengers. 
An  array  (of  three  elements)  is  used  to  store  the  values  in  that 
sequence. 

data  type:  int[] 

Table  2 1 .  Attributes  for  Item  SimEntity  Object 


(e)  Entry  SimEntity 

The  Entry  SimEntity  object  is  used  to  keep  track  of  when  an  aircraft  is 
added  and  removed  from  the  holding  list  to  support  the  simulation  as  well  as  for  post¬ 
simulation  review.  The  following  table  describes  the  attributes  defined  for  the  entity. 
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A. 

Parameter 

1. 

id 

Identifier  for  the  record  entry  entity. 

data  type:  int 

B. 

State  Variable 

2. 

aircraft 

The  aircraft  entity  that  the  record  entry  is  created  for. 

data  type:  Aircraft 

3. 

startTime 

The  time  when  the  record  entry  is  created,  i.e.,  when  an  aircraft 
requests  for  new/next  assignment. 

data  type:  double 

4. 

endTime 

The  time  when  the  record  entry  is  closed,  i.e.,  when  the  aircraft 
gets  its  assignment  or  when  it  retracts  the  request  because  it 
encountered  failure. 

data  type:  double 

Table  22.  Attributes  for  Entry  SimEntity  Object 


2.  Aircraftinitializer  Component 

This  component  is  responsible  for  the  creation  and  initialization  of  the  list  of 
entities  for  each  aircraft  type.  Two  Aircraftinitializer  components  are  therefore 
instantiated  for  the  simulation,  one  for  the  CH-53  and  the  other  for  the  SH-60  aircraft 
type.  The  following  figure  depicts  the  component  event  graph,  and  the  specific  events 
are  described  in  Table  23. 
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Figure  17.  Event  Graph  for  Aireraftinitializer  Component 


S/N 

Event 

Purpose 

1. 

Run 

Triggers  the  InitAircraft  event  immediately  at  the  start  of 
simulation. 

2. 

InitAircraft 

Creates  aireraft  entity,  sets  its  parameters  and  initializes  its 
state  variables,  i.e., 

•  set  aireraft  identifier, 

•  set  aireraft  type, 

•  set  aireraft  capacity, 

•  set  aircraft  speed, 

•  set  aircraft  mean  time  for  unloading  the  various  load 
types, 

•  set  aircraft  maximum  range  (i.e.,  before  requiring 
refueling), 

•  set  aircraft  minimum  buffer  time, 

•  set  aircraft  minimum  buffer  factor, 

•  initialize  aircraft  need  for  refuel  to  false, 

•  initialize  aircraft  need  for  repair  to  false, 

•  initialize  aircraft  expected  return  time  to  ship  to  zero. 

72 


S/N 

Event 

Purpose 

•  initialize  aircraft’s  next  assigned  landing  spot  to  null, 

•  initialize  aircraft’s  assignment  to  null, 

•  initialize  aircraft’s  total  sorties  flown  to  zero, 

•  initialize  aircraft  status  to  zero, 

•  initialize  aircraft  state  to  zero,  and 

•  initialize  aircraft  travelled  distance  from  zero  for  the  first 
aircraft  up  to  half  the  maximum  range  for  the  last  aircraft 
with  constant  increment.  This  is  to  simulate  some 
staggering  in  the  refueling  need  for  the  aircraft  fleet, 
which  is  more  representative  of  actual  operations. 

Loops  itself  for  (pk  -  1)  times  so  as  to  generate  the  total 
number  for  that  aircraft  type,  and  passes  the  aircraft  entity  to 
Scheduler  and  AircraftServer  instances  via  UpdateAircraftList 
and  CreateAircraft  event  respectively. 

3. 

UpdateAircraftList 

Does  nothing;  meant  to  be  heard  by  Scheduler. 

4. 

CreateAircraft 

Does  nothing;  meant  to  be  heard  by  AircraftServer  instances. 

Table  23.  Events  for  Aircraftinitializer  Component 


3.  AircraftServer  Component 

The  AireraftServer  component  is  responsible  for  managing  the  entities  of  a 
specific  aircraft  type  by  keeping  track  of  their  status,  and  updates  the  Scheduler  and 
ShipServer  components  as  and  when  information  is  required  to  coordinate  the  activities. 
It  is  also  responsible  for  generating  the  “aircraft-led”  events,  which  fall  under  the 
delivery,  unloading,  recovery  and  servicing  phases  of  the  airlift  operation  process.  The 
following  two  figures  depict  the  component  event  graph,  and  the  specific  events  are 
detailed  in  Table  24. 
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Figure  18.  Event  Graph  for  AircraftServer  Component  (Part  1) 
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Figure  19.  Event  Graph  for  AircraftServer  Component  (Part  2) 
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S/N 

Event 

Purpose 

1. 

Run 

Performs  state  initialization  for  the  following  variables  at  the 
start  of  simulation,  i.e., 

•  initialize  the  lists  of  ready  aircraft  (Arr)  and  planned 
aircraft  (Apr)  to  null, 

•  initialize  the  numbers  of  aircraft  for  the  various  recording, 
i.e.,  available,  loading,  delivery,  unloading,  recovery, 
refueling,  repairing  and  waiting  (Nar,  Nlr,  Ndr,  Nur,  Nrr, 
Nrfr,  Nrpr  and  Nwr  respectively),  to  zero, 

•  initialize  the  standby  landing  spot  list  (LwO  to  null, 

•  initialize  the  number  of  load  delivered  (Qr[1|)  by  aircraft 
type  k  to  zero,  and 

•  initialize  the  number  of  sorties  flown  (Fr)  by  aircraft  type  k 
to  zero. 

2. 

CreateAircraft 

Listens  to  Aircraftinitializer  for  newly  created  aircraft  and 
performs  the  following: 

•  update  aircraft  status  and  state  accordingly, 

•  increase  the  number  of  available  aircraft  (Nar)  by  one,  and 

•  trigger  NeedSupport  event  after  tpR  time  delay  with  the 
aircraft  and  support  type  (i.e.,  with  value  1)  passed  on  as 
argument  to  simulate  a  downstream  aircraft  failure. 

3. 

NeedSupport 

Does  nothing;  meant  to  be  heard  by  Scheduler 

4. 

Tasking 

Listens  to  Scheduler  for  load  assignment  (via  the  assigned 
landing  spot)  and  performs  one  of  the  following: 

•  trigger  MakeReady  event  and  pass  the  assigned  aircraft  as 
argument  if  the  aircraft  is  available,  or  otherwise 

•  trigger  MakePlan  event  for  the  assigned  aircraft  and  pass 
the  assigned  aircraft  as  argument. 

5. 

MakeReady 

Adds  aircraft  to  the  ready  list  (Arr)  and  increases  the  number 
of  waiting  aircraft  (Nwr)  by  one. 

6. 

MakePlan 

Adds  aircraft  to  the  planned  list  (Apr). 

7. 

CheckAircraft 

Listens  to  ShipServer  instances  for  landing  spot  and  checks 
whether  its  assigned  aircraft  is  ready  for  next  assignment.  If 
the  aircraft  is  ready,  removes  it  from  the  ready  list  (Arr)  and 
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assigns  the  landing  spot  to  it. 

Triggers  AircraftStatus  event  immediately  with  the  aircraft 
readiness  status  passed  on  as  argument. 

8. 

AircraftStatus 

Does  nothing;  meant  to  be  heard  by  ShipServer  instances. 

9. 

StartLoading 

Listens  to  ShipServer  instances  for  landing  spot  to  commence 
loading  of  its  assigned  aircraft  and  performs  the  following: 

•  update  the  aircraft  state  accordingly, 

•  decrease  number  of  waiting  aircraft  (Nwk)  by  one, 

•  remove  landing  spot  from  standby  list  (LwO  if  it  is  in  it, 

•  remove  aircraft  from  the  ready  list  (ARk),  and 

•  increase  the  number  of  loading  aircraft  (Nlr)  by  one. 

10. 

StandbyLoading 

Adds  landing  spot  entity  to  the  standby  list  (LwO,  to  wait 

for  the  assigned  aircraft  to  be  ready  for  load-up. 

11. 

StartSortie 

Listens  to  ShipServer  instances  for  an  assigned  aircraft  to 
commence  the  delivery  sortie  and  performs  the  following: 

•  update  the  aircraft  state  accordingly, 

•  timestamp  mission  time  and  update  its  assignment  record, 

•  increase  number  of  sorties  flown  (Fk)  by  one, 

•  decrease  number  of  loading  aircraft  (Nkk)  by  one  and  add  it 
to  the  number  of  delivery  aircraft  (Nok), 

•  compute  expected  return  time  for  aircraft, 

•  trigger  ReachTarget  event  after  tokij]  time  delay  to  simulate 
travel  time  with  the  landing  spot  entity  passed  on  as 
argument, 

•  trigger  NeedSupport  event  immediately  with  the  aircraft 
passed  on  as  argument  together  with  the  support  type  (i.e., 
value  =  0),  if  it  requires  refueling  upon  return  to  ship,  and 

•  trigger  UpdateAircraftList  event  immediately  with  the 
aircraft  passed  on  as  argument  for  Scheduler  to  detail  the 
next  assignment,  if  it  does  not  require  repair  at  this 
juncture. 

12. 

UpdateAircraft 

List 

Does  nothing;  meant  to  be  heard  by  Scheduler. 

13. 

ReachTarget 

Reaches  designated  target  area  to  start  unloading  and  performs 
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the  following: 

•  update  aircraft  state  and  its  travelled  distance  accordingly, 

•  timestamp  mission  time  and  update  its  assignment  record, 

•  increase  number  of  loads  delivered  (Qk[i])  by  the  load 
transfer  amount  as  stored  in  its  assignment  record, 

•  decrease  number  of  delivery  abcraft  (Nok)  by  one  add  it  to 
the  number  of  unloading  abcraft  (Nuk),  and 

•  trigger  LeaveTarget  event  next  with  tuk[j]  time  delay  to 
simulate  the  unloading  process  and  the  abcraft  is  passed  on 
as  argument. 

14. 

LeaveTarget 

Completes  unloading  process  with  the  aircraft  returning  to  ship 
and  performs  the  following: 

•  update  the  aircraft  state  accordingly, 

•  timestamp  mission  time  and  update  its  assignment  record, 

•  decrease  number  of  unloading  aircraft  (Nuk)  by  one,  add  it 
to  the  number  of  recovery  aircraft  (Nnk),  and 

•  trigger  EndSortie  event  next  with  tRkiji  time  delay  to 
simulate  the  travel  time  and  the  aircraft  is  passed  on  as 
argument. 

15. 

EndSortie 

Completes  the  sortie  and  performs  the  following: 

•  update  abcraft  state  and  its  bavelled  distance  accordingly, 

•  timestamp  mission  time,  compute  actual  time  taken  for 
sortie,  update  its  assignment  record,  and 

•  decrease  the  number  of  recovery  aircraft  (Nuk)  by  one. 

Triggers  one  of  the  following  immediately  with  the  aircraft 
passed  on  as  argument  based  on  the  stated  conditions: 

•  SeekSupport  event  if  the  aircraft  needs  refueling  and/or 
repab  and  increase  the  number  of  waiting  aircraft  (Nwk)  by 
one,  or  otherwise 

•  Ready  event  to  indicate  it  is  ready  for  next  assignment. 

16. 

SeekSupport 

Does  nothing;  meant  to  be  heard  by  Scheduler. 

17. 

StartRefuel 

Listens  to  Scheduler  for  aircraft  to  start  refueling  and  performs 
the  following: 
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•  update  aircraft  state  accordingly, 

•  timestamp  mission  time  and  update  its  assignment  record, 

•  decrease  number  of  waiting  aircraft  (Nwk)  by  one, 

•  decrease  number  of  refueling  aircraft  (NRFk)  by  one,  and 

•  trigger  EndRefuel  event  next  with  Irfr  time  delay  to 
simulate  the  refueling  process  and  the  aircraft  is  passed  on 
as  argument. 

18. 

EndRefuel 

Completes  refueling  and  performs  the  following: 

•  update  aircraft  state,  reset  its  refuel  need  and  distance 
travelled  accordingly, 

•  timestamp  mission  time  and  update  its  assignment  record, 
and 

•  increase  the  number  of  refueling  aircraft  (Nkfr)  by  one. 

Triggers  one  of  the  following  events  immediately  based  on  the 
stated  conditions: 

•  StartRepair  event  with  the  aircraft  passed  on  as  argument  if 
aircraft  needs  to  be  repaired  and  increase  number  of 
waiting  aircraft  (Nwk)  by  one,  or  otherwise 

•  Ready  event  with  the  aircraft  passed  on  as  argument  and 
ReleaseLandingSpot  event  with  the  landing  spot  passed  on 
as  argument  to  relieve  the  landing  spot  for  next  tasking. 
The  support  aircraft  for  the  landing  spot  is  set  to  null. 

19. 

StartRepair 

Listens  to  Scheduler  (and  EndRefuel  event)  for  aircraft  to  start 
the  repairing  work  and  performs  the  following: 

•  timestamp  mission  time  and  update  its  assignment  record, 

•  decrease  number  of  waiting  aircraft  (Nwk)  by  one, 

•  increase  number  of  repairing  aircraft  (Nkpr)  by  one,  and 

•  trigger  EndRepair  event  next  with  Irpr  time  delay  to 
simulate  the  repair  process  and  the  aircraft  is  passed  on  as 
argument. 

20. 

EndRepair 

Completes  refueling  and  performs  the  following: 

•  update  aircraft  state  and  reset  its  repair  need  and  support 
aircraft  accordingly, 

•  timestamp  mission  time  and  update  its  assignment  record 
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•  decrease  number  of  refueling  aircraft  (Nkfr)  by  one  and 
add  it  to  the  number  of  available  aircraft  (Nar), 

•  trigger  ReleaseLandingSpot  event  immediately  with  the 
landing  spot  passed  on  as  argument, 

•  trigger  Recheck  event  immediately, 

•  trigger  UpdateAircraftList  immediately  event  with  the 
landing  spot  passed  on  as  argument  to  seek  the  next 
assignment,  and 

•  trigger  NeedSupport  event  with  tpk  time  delay  to  simulate 
another  downstream  failure  and  the  landing  spot  is  passed 
on  as  argument  together  with  the  support  code. 

21. 

Ready 

Prepares  aircraft  for  next  assignment  and  performs  the 
following: 

•  timestamp  mission  time  and  update  aircraft’s  assignment 
record  before  resetting  its  assignment  record  to  null, 

•  update  aircraft  state  accordingly,  and 

•  increase  number  of  available  aircraft  (Nar)  by  one. 

Triggers  one  of  the  following  events  immediately: 

•  Handover  event  with  assigned  landing  spot  passed  on  as 
argument  and  remove  aircraft  from  the  planned  list  (Apr),  if 
the  aircraft  is  scheduled  for  next  assignment  and  the 
assigned  landing  spot  is  ready  to  start  loading,  or 

•  MakeReady  event  with  the  aircraft  passed  on  as  argument 
and  Recheck  event  and  remove  aircraft  from  the  planned 
list  (Apr),  is  scheduled  for  next  assignment  but  the  assigned 
landing  spot  is  not  ready  (still  preparing  the  load),  or 
otherwise 

•  Recheck  event. 

22. 

Handover 

Shortlists  the  landing  spot  for  loading  when  the  crew  is  next 
available  since  its  assigned  aircraft  is  ready  by  performing  the 
following: 

•  remove  landing  spot  from  standby  list  (Lwi), 

•  increase  number  of  waiting  aircraft  (Nwr)  by  one, 

•  decrease  the  number  of  available  aircraft  (Nar)  by  one,  and 

•  add  the  aircraft  to  the  ready  list  (Arr). 
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The  event  is  meant  to  be  heard  by  ShipServer  instances  as  well. 

23. 

UpdateFailed 

Aircraft 

Removes  aircraft  from  the  ready  list  (Arr)  if  it  is  in  ready  state 
or  otherwise  from  the  planned  list  (Apk). 

24. 

Recheck 

Does  nothing;  meant  to  be  heard  by  ShipServer  instances. 

25. 

ReleaseLanding 

Spot 

Does  nothing;  meant  to  be  heard  by  ShipServer  instances. 

26. 

Update 

Replacement 

Aircraft 

Listens  to  Scheduler  for  replacement  aircraft  and  performs  one 
of  the  following: 

•  trigger  MakeReady  and  Handover  events  with  the  aircraft 
and  assigned  landing  spot  passed  on  as  argument 
respectively,  if  the  aircraft  is  available,  or  otherwise 

•  trigger  MakePlan  event  with  the  assigned  aircraft  passed  on 
as  argument. 

27. 

UpdateLanding 

Spot 

Listens  to  Scheduler  for  failed  aircraft  and  removes  its  assigned 
landing  spot  from  the  standby  list  (LwO,  i.e.,  if  the  landing  spot 
is  loaded  and  waiting  for  the  aircraft  to  perform  the  load-up. 

Table  24.  Events  for  AircraftServer  Component 


4.  ShipServer  Component 

Initially,  the  ShipServer  component  is  responsible  for  the  creation  and 
initialization  of  a  specific  ship  entity.  In  this  case,  there  are  three  ShipServer  objects 
instantiated  for  the  JMSDF,  LPD-19  and  HJSV  respectively.  Each  ShipServer  object 
manages  the  resources  onboard  the  ship,  including  the  logistics  crew  and  landing  spots,by 
keeping  track  of  their  status,  and  updates  the  Scheduler  and  ShipServer  components  as 
and  when  information  is  required  to  coordinate  the  activities.  It  is  also  responsible  for 
generating  the  “landing  spot-led”  events,  which  fall  under  the  preparation  and  loading 
phases  of  the  airlift  operation  process.  The  following  two  figures  depict  the  component 
event  graph  and  the  specific  events  are  detailed  in  Table  25. 
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Figure  20. 


Event  Graph  for  ShipServer  Component  (Part  1) 
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Figure  2 1 .  Event  Graph  for  ShipServer  Component  (Part  2) 
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1. 

Run 

Creates  a  ship  entity  (aO  and  sets/initializes  its  attributes  at  the 
start  of  simulation  to: 

•  set  ship  identifier  i,  i.e,.  i  =  0,  1  and  2  for  JMSDF,  LPD-17 
and  JHSV  respeetively, 

•  set  number  of  landing  spots, 

•  set  number  of  logistics  crew, 

•  set  meantime  for  preparing  the  various  load  types,  which  is 
specific  to  the  aircraft  type  used  for  the  airlift, 

•  set  meantime  for  loading  the  various  load  types,  which  is 
specific  to  the  aircraft  type  used  for  the  airlift,  and 

•  create  a  list  of  landing  spots  and  initializes  it  to  null. 

Performs  initialization  of  the  following  state  variables  for  each 
ship  with  identifier  i: 

•  initialize  number  of  available  crew  (Ci)  to  total  number  of 
logistics  crew  (ri), 

•  initialize  number  of  available  landing  spots  (NAi)  to  total 
number  of  landing  spots  (ni),  number  of  landing  spots 
defined  for  other  recording  purposes,  i.e.,  active,  standby 
and  support  (NAi,  NWi  and  NSi)  to  zero, 

•  initialize  the  landing  spot  lists  defined  for  the  various 
recording,  i.e.,  available,  active,  priority,  standby  and 
support  (  LAi,  LLi,  LPi,  LWi  and  LS  respectively),  to  null, 
and 

•  initialize  remaining  load  (Qi[l])  to  the  quantity  allocated  to 
the  ship  (qil)  for  load  type  1,  i.e.,  1  =  0,  1,  2  for  cargo, 
equipment  and  passengers  respectively. 

Triggers  the  InitLS  and  CreateShip  events  immediately 
afterward. 

2. 

InitLS 

Creates  landing  spot  entity  and  sets/initializes  its  attributes  to: 

•  set  landing  spot  identifier, 

•  set  landing  spot’s  associated  ship, 

•  initialize  assignment  to  null, 

•  initialize  support  aircraft  to  null,  and 

•  insert  landing  spot  entity  to  the  ship’s  landing  spot  list. 
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Adds  landing  spot  entity  to  the  available  landing  spot  list  (Lai). 

Triggers  the  InitLS  event  immediately  if  the  number  of  created 
landing  spot  entities  is  less  than  the  ship’s  total  number  of 
landing  spots  (rO  and  increase  the  number  created  (counter) 
each  time. 

3. 

InitOperation 

Removes  first  available  landing  spot  from  the  list  (LaO  and 
decreases  number  of  available  landing  spots  (Nai)  by  one. 

Triggers  CheckTask  event  immediately  and  passes  landing  spot 
as  argument  to  Scheduler  to  check  for  new  task,  which  could 
be  an  airlift  assignment  or  provide  support  service. 

4. 

CreateShip 

Does  nothing;  meant  to  be  heard  by  Scheduler  and  Recorder. 

5. 

CheckTask 

Does  nothing;  meant  to  be  heard  by  Scheduler. 

6. 

Tasking 

Listens  for  tasking  from  Scheduler  and  triggers  one  of  the 
following  events  immediately  based  on  the  tasking  issued  with 
the  requesting  landing  spot  entity  passed  on  as  argument,  i.e., 

•  StandbySupport,  if  landing  spot  is  required  to  provide 
service  support,  or  otherwise 

•  StartPrepare,  if  there  are  loads  to  be  transferred  and  crew  is 
available,  or  otherwise 

•  Reset. 

7. 

StandbySupport 

Adds  the  landing  spot  to  the  support  list  (Ls),  reserved  to 
provide  support  services,  and  increases  number  of  standby 
landing  spots  for  the  associated  ship  (Nsi)  by  one. 

8. 

Reset 

Inserts  landing  spot  entity  back  to  the  available  list  (Lai)  and 
increases  number  of  available  landing  spots  (NaO  by  one. 

9. 

StartPrepare 

Commences  load  preparation  for  an  airlift  assignment  and 
performs  state  transition  for  the  following  variables: 

•  decrease  number  of  available  crew  (Ci)  by  one, 

•  add  landing  spot  to  the  active  list  (LlO  and  increase  number 
of  active  landing  spots  (Nu)  by  one, 

•  decrease  remaining  quantity  (Qipj)  by  the  load  transfer 
amount  (as  stored  in  the  landing  spot’s  assignment  record), 
and 

•  timestamp  the  mission  time  and  update  the  assignment 
record. 

Triggers  EndPrepare  event  after  tpik  time  delay  and  passes  the 
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landing  spot  as  argument. 

10. 

EndPrepare 

Completes  load  preparation  and  performs  state  transition  for 
the  following  variables: 

•  increase  number  of  available  crew  (CO  by  one, 

•  remove  landing  spot  from  the  active  list  (LlO  and  decrease 
number  of  active  landing  spots  (Nu)  by  one,  and 

•  timestamp  the  mission  time  and  update  the  assignment 
record. 

Triggers  one  of  the  following  events  immediately  with  the 
landing  spot  passed  on  as  argument: 

•  FindReplacement  event,  if  its  assigned  aircraft  has  been  re¬ 
assigned  (i.e.,  after  it  has  failed  and  is  being  repaired),  or 
otherwise 

•  CheckAircraft  event  to  check  whether  the  aircraft  is  ready. 

11. 

CheckAircraft 

Does  nothing;  meant  to  be  heard  by  Aircrafts erver  instances. 

12. 

AircraftStatus 

Listens  for  aircraft  status  from  Aircrafts  erver  instances  and 
triggers  one  of  the  following  events  immediately  with  the 
landing  spot  passed  on  as  argument: 

•  FindReplacement  event,  if  assigned  aircraft  is 

unserviceable,  or  otherwise 

•  StartLoading  event,  if  aircraft  is  available  and  in 
serviceable  state  with  available  crew,  or  otherwise 

•  StandbyLoading  and  Recheck  events  for  new  task. 

13. 

StartLoading 

Commences  loading  for  an  airlift  assignment  and  performs 
state  transition  for  the  following  variables: 

•  decrease  number  of  available  crew  (Ci)  by  one, 

•  add  landing  spot  to  active  list  (Lu)  and  increase  number  of 
active  landing  spots  (NlO  by  one, 

•  remove  landing  spot  from  standby  list  (LwO  if  it  is  in  the 
list,  and 

•  timestamp  the  mission  time  and  update  the  assignment 
record. 

Triggers  EndLoading  event  after  tLik  time  delay  with  the 
landing  spot  entity  passed  on  as  argument. 

The  event  is  meant  to  be  heard  by  Aircrafts  erver  instances  as 
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well. 

14. 

StandbyLoading 

Adds  landing  spot  entity  to  the  standby  list  (Lwi)  and  inereases 
the  number  of  standby  landing  spots  (NwO  by  one,  to  wait  for 
the  assigned  aireraft  to  be  ready  for  load-up. 

The  event  is  meant  to  be  heard  by  AireraftServer  instanees  as 
well. 

15. 

Recheck 

Checks  for  available  resources  and  performs  one  of  the 
following: 

•  triggers  StartLoading  event  if  there  are  available  crew  (Ci) 
and  awaiting  landing  spot  in  the  priority  list  (LPi). 
Removes  the  first  landing  spot  from  LPi  and  passes  it  as  the 
argument,  or 

•  triggers  CheckTask  event  if  there  are  available  logistics 
crew  (Ci)  and  landing  spot  (LAi).  Removes  the  first 
landing  spot  from  LAi,  decrease  number  of  available 
landing  spots  (NAi)  by  one  and  pass  landing  spot  as  the 
argument  together  with  current  crew  size,  or 

•  does  nothing  otherwise. 

16. 

FindReplacement 

Does  nothing;  meant  to  be  heard  by  Scheduler. 

17. 

EndLoading 

Completes  the  loading  for  an  airlift  assignment  and  performs 
state  transition  for  the  following  variables: 

•  increase  number  of  available  crew  (Ci)  by  one, 

•  remove  landing  spot  from  active  list  (LLi)  and  decrease 
number  of  active  landing  spots  (NLi)  by  one, 

•  add  landing  spot  to  the  available  list  (LAi)  and  increase 
number  of  available  landing  spots  (NAi)  by  one, 

•  timestamp  the  mission  time  and  update  the  assignment 
record,  and 

•  hand  over  the  assignment  record  to  the  aircraft  and  set  the 
landing  spot’s  assignment  to  null. 

Triggers  StartSortie  and  Recheck  event  immediately  with 
aircraft  entity  passed  on  as  argument  for  StartSortie. 

18. 

StartSortie 

Does  nothing;  meant  to  be  heard  by  AireraftServer  instances. 

19. 

Handover 

Listens  to  AireraftServer  instances  for  ready  aircraft  that  has  an 
assigned  landing  spot  waiting  to  start  the  next  assignment. 

Triggers  StartLoading  event  if  there  is  crew  (CO  available  or 
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otherwise,  GetReady  event. 

20. 

GetReady 

Adds  landing  spot  to  the  priority  list  (Lpi)  so  that  it  will  be 
aetivated  for  loading  when  the  next  erew  is  available. 

21. 

NeedSupport 

Listens  to  AireraftServer  instanees  for  aircraft  requiring 
servicing  (refuel  and/or  repair)  and  performs  the  following  if 
there  is  available  landing  spot  (Lai): 

•  remove  the  first  landing  spot  from  Lai, 

•  decrease  number  of  available  landing  spots  (Nai)  by  one, 
and 

•  trigger  CheckTask  event  and  pass  landing  spot  as  the 
argument  together  with  the  crew  size. 

22. 

ReleaseLanding 

Spot 

Listens  to  AireraftServer  instances  for  completed  support 
service  work  and  performs  the  following: 

•  remove  landing  spot  from  support  list  (Ls)  and  decrease 
number  of  support  landing  spots  for  the  associated  ship 
(Nsi)  by  one,  and 

•  add  landing  spot  to  available  list  (Lai)  and  increase  number 
of  available  landing  spots  (Nai)  by  one. 

23. 

UpdateLanding 

Spot 

Listens  to  Scheduler  for  failed  aircraft  and  performs  the 
following  if  its  assigned  landing  spot  is  in  the  standby  list  (Ls), 
i.e.,  waiting  for  the  aircraft  to  start  its  next  assignment: 

•  remove  landing  spot  from  the  standby  list  (LwO, 

•  remove  landing  spot  from  priority  list  (Lpi)  if  in  the  list, 

•  decrease  number  of  standby  landing  spots  (NwO  by  one, 
and 

•  trigger  FindReplacement  event  immediately  with  landing 
spot  passed  on  as  argument. 

24. 

ResetLanding 

Spot 

Listens  to  Scheduler  to  redeploy  the  landing  spot  and  performs 
the  following: 

•  add  the  load  transfer  amount  (as  stored  in  the  landing  spot’s 
assignment  record)  to  the  remaining  load  (QO  for  the  ship, 

•  reset  landing  spot’s  assignment  to  null,  and 

•  add  landing  spot  to  the  available  list  (Lai)  and  increase 
number  of  available  landing  spots  (Nai)  by  one,  and 
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•  triggers  NeedSupport  event  immediately  after  that. 

This  event  is  only  applicable  when  Replacement  Mode  #1  is 
selected  for  the  simulation. 

Table  25.  Events  for  ShipServer  Component 


5.  Scheduler  Component 

The  Scheduler  is  essentially  the  overall  management  system  for  the  fleet 
operation,  handling  all  the  tasking  and  resource  allocation  activities.  The  following  three 
figures  depict  the  component  event  graph.  The  specific  events  are  described  in  Table  26. 
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Figure  22.  Event  Graph  for  Scheduler  Component  (Part  1) 
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Figure  23.  Event  Graph  for  Scheduler  Component  (Part  2) 
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Figure  24.  Event  Graph  for  Scheduler  Component  (Part  3) 
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1. 

Run 

Performs  initialization  for  the  following  state  variables  at 
the  start  of  the  simulation: 

•  initialize  assignment  list  (A)  to  null, 

•  initialize  aircraft  holding  list  (Ah)  to  null, 

•  initialize  aircraft  holding  record  (H)  to  null, 

•  initialize  the  list  of  aircraft  requiring  support  (As)  to 
null, 

•  initialize  the  list  of  aircraft  waiting  for  support  (Aw)  to 
null, 

•  initialize  landing  spot  replacement  list  (Lr)  to  null, 

•  initialize  the  support  landing  spot  list  (Ls)  to  null, 

•  initialize  number  of  support  landing  spots  from  ship 
entity  with  identifier  i  (NsO  to  zero, 

•  initialize  number  of  landing  spots  for  ship  entity  with 
identifier  i  (Ni)  to  zero, 

•  initialize  minimum  number  of  landing  spots  required  to 
for  direct  airlift  operation  support  for  ship  entity  with 
identifier  i  (NmO  to  Hli, 

•  initialize  remaining  quantity  of  load  type  1  for  ship 
entity  with  identifier  i  (Qipj)  to  zero,  and 

•  initialize  remaining  quantity  of  load  type  1  for  the  fleet 
(Q[il)  to  zero. 

2. 

UpdateAircraftList 

Listens  to  AircraftServer  instances  for  aircraft  requesting 
new  assignment  and  performs  the  following: 

•  create  a  new  entry  for  the  aircraft  and  set  the  time-in 
using  current  time,  add  it  to  the  holding  record  (H)  and 
set  aircraft’s  entry  accordingly,  and 

•  add  aircraft  to  the  holding  list  (Ah),  sorted  using 
aircraft’s  expected  time  available  for  next  assignment. 

If  Replacement  Mode  #0  scheme  is  selected  for  the 
simulation,  the  following  will  be  performed: 

•  the  aircraft  will  be  checked  against  the  replacement  list 
(Lr)  first  to  determine  if  there  is  a  landing  spot  with  an 
assigned  aircraft  of  the  same  type  before  adding  it  to 
the  holding  list.  If  there  is,  a  new  assignment  will  be 
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created  for  this  aircraft  instead,  inheriting  the  assigned 
landing  spot  and  prepared  load  from  the  failed  aircraft. 
The  landing  spot  is  removed  from  the  list  (Lr),  and 

•  UpdateReplacementAircraft  and  StandbyLoading 
events  will  be  triggered  immediately  with  the  aircraft 
and  landing  spot  passed  on  as  argument  respectively, 
and 

•  AircraftStatus  event  will  also  be  triggered  immediately 
with  the  landing  spot  and  the  aircraft’s  availability 
status  passed  on  as  argument. 

3. 

UpdateReplacement 

Aircraft 

Does  nothing;  meant  to  be  heard  by  AircraftServer 
instances. 

4. 

StandbyLoading 

Does  nothing;  meant  to  be  heard  by  AircraftServer  and 
ShipServer  instances. 

5. 

AircraftStatus 

Does  nothing;  meant  to  be  heard  by  ShipServer  instances. 

6. 

CreateShip 

Listens  to  ShipServer  instances  for  the  newly  created  ship 
entities  and  performs  the  following: 

•  get  the  entity’s  allocated  load  quantity  and  update  the 
remaining  load  quantity  (Qi|i|)  for  that  ship  and  the 
remaining  load  quantity  (Qpj)  for  the  fleet,  and 

•  get  the  entity’s  total  landing  spots  and  update  the 
number  of  landing  spots  (Ni)  for  that  ship. 

7. 

NeedSupport 

Listens  to  AircraftServer  instances  for  aircraft  requiring 
support  services  and  performs  the  following: 

•  set  aircraft’s  need  for  refuel  or  repair  indicator  to  true 
based  on  the  support  type  required, 

•  add  aircraft  to  the  need  support  list  (As)  if  it  is  not  in  it, 

•  trigger  UpdateResources  event  immediately  with  the 
aircraft  passed  on  as  argument,  if  repair  service  is 
required,  and 

•  trigger  SeekSupport  event  immediately  with  the  aircraft 
passed  on  as  argument,  if  aircraft  is  available  or  waiting 
for  load-up. 

8. 

CheckTask 

Listens  to  ShipServer  instances  for  landing  spot  checking 
for  task  and  triggers  one  of  the  following  immediately: 

•  CheckSupport  event  with  the  landing  spot  and  crew 
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size  passed  on  as  argument,  if  there  is  aireraft  requiring 
or  waiting  for  support  (Aw),  or  otherwise 

•  CheckLoad  event  with  the  landing  spot  passed  on  as 
argument,  if  the  holding  list  (Ah)  is  not  empty  and 
crew  is  available,  or  otherwise 

•  Tasking  event  with  the  landing  spot  and  load  type 
passed  on  as  argument.  The  load  type  is  set  as  “9999” 
to  indicate  no  tasking. 

9. 

CheckSupport 

Checks  whether  the  landing  spot  is  required  for  support 
service  by  performing  one  of  the  following: 

•  if  there  is  aircraft  waiting  for  support  (Aw), 

■  trigger  either  StateRefuel  or  StartRepair  event 

immediately,  based  on  the  support  type  required 
with  the  aircraft  and  landing  spot  passed  on  as 
argument, 

■  remove  aircraft  Ifom  the  need  support  list  (As)  if  it  is 

in  it, 

■  decrease  the  number  of  support  landing  spots  from  its 

ship  (Nsi)  by  one, 

■  trigger  Tasking  event  immediately  with  the  landing 

spot  and  load  type  passed  on  as  argument.  The  load 
type  is  set  as  “8888”  to  indicate  a  support  tasking,  or 

•  if  the  support  landing  spots  from  its  ship  has  not 
exceeded  the  individual  ship  quota  (i.e.,  Nsi  <  Ni  -  NmO 
and  overall  list  is  (Ls)  is  less  than  the  maximum 
number  allowable  for  the  fleet  (ns),  or  there  are  no 
remaining  loads  (Qim)  left  for  the  ship, 

■  add  landing  spot  to  the  support  list  (Ls), 

■  increase  the  number  of  support  landing  spots  from  its 

ship  (Nsi)  by  one,  and 

■  trigger  Tasking  event  immediately  with  the  landing 

spot  and  load  type  passed  on  as  argument.  The  load 
type  is  set  as  “8888”  for  the  same  reason,  or 

•  if  there  is  crew  available,  trigger  CheckLoad  event  with 
the  landing  spot  passed  on  as  argument,  or  otherwise 

•  trigger  Tasking  event  immediately  with  landing  spot 
passed  on  as  argument  together  with  the  load  type  set 
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to  “9999”  to  indicate  no  tasking. 

10. 

CheckLoad 

Initiates  load  assignment  process  by  performing  one  of  the 
following: 

•  trigger  Tasking  event  immediately  with  landing  spot 
and  load  type  passed  on  as  argument,  if  there  is  no 
aircraft  in  the  holding  list  (Ah)  or  all  loads  for  that  ship 
(Qi[i])  have  been  transferred.  The  load  type  is  set  as 
“9999”  to  indicate  no  tasking,  or 

•  trigger  AllocationModeO  or  AllocationModel  event 
based  on  the  selected  for  the  simulation  and  pass  on 
landing  spot  as  argument. 

11. 

A  llocationModeO 

Performs  load  allocation  based  on  ship-level  consideration 
only,  as  per  the  discussion  in  the  Design  section. 

Triggers  Allocate  event  immediately  with  landing  spot, 
aircraft  and  load  type  passed  on  as  argument,  if  there  is  a 
match  or  otherwise,  the  Tasking  event  with  landing  spot 
passed  on  as  argument  together  with  the  load  type  set  to 
“9999”  to  indicate  no  tasking. 

12. 

AllocationModel 

Performs  load  allocation  based  on  fleet-level  consideration 
only  as  per  the  discussion  in  the  Design  section. 

Triggers  Allocate  event  immediately  with  landing  spot, 
aircraft  and  load  type  passed  on  as  argument,  if  there  is  a 
match  or  otherwise,  the  Tasking  event  with  landing  spot 
passed  on  as  argument  together  with  load  type  set  to 
“9999”  to  indicate  no  tasking. 

13. 

Allocate 

Performs  load  allocation  for  the  landing  spot  and  the 
assigned  aircraft  as  follows: 

•  remove  aircraft  from  holding  list  (Ah),  assign  landing 
spot  as  its  next  landing  spot,  set  time-out  for  its  entry 
record  using  current  time  and  change  its  status  to  one, 

•  compute  the  load  transfer  amount  (j)  and  update  the 
assignment  record  based  on  the  discussed  formula,  i.e., 

I  Cki,  Qnn  >  Cki 

qi  =  \ 

\Qm,  Otherwise 

•  decrease  remaining  load  left  for  the  ship  (Qi|i])  and  fleet 
by  (Q[i])  the  load  transfer  amount,  and 

•  trigger  Tasking  event  immediately  with  the  landing 
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spot  and  load  type  passed  on  as  argument. 

14. 

Tasking 

Does  nothing;  meant  to  be  heard  by  AircraftServer  and 
ShipServer  instances. 

15. 

StartRefuel 

Does  nothing;  meant  to  be  heard  by  AircraftServer 
instances. 

16. 

StartRepair 

Does  nothing;  meant  to  be  heard  by  AircraftServer 
instances. 

17. 

SeekSupport 

Listens  to  AircraftServer  instances  for  returned  aircraft 
seeking  support  and  performs  one  of  the  following: 

•  if  there  are  landing  spots  in  the  support  list  (Ls), 

■  remove  landing  spot  from  support  list  (Ls)  and 

decrease  number  of  support  landing  spots  for  the 
associated  ship  (NsO  by  one,  and 

■  trigger  either  StateRefuel  or  StartRepair  event 

immediately  based  on  the  support  type  required  with 
the  aircraft  and  landing  spot  passed  on  as  argument, 
or  otherwise 

•  add  aircraft  to  the  list  awaiting  for  support  (Aw). 

18. 

UpdateResources 

Updates  resources  due  to  an  aircraft  failure  by  performing 
the  following: 

•  remove  failed  aircraft  from  the  holding  list  (Ah)  if  it  is 
on  it,  or  otherwise,  trigger  UpdateLandingSpot 
immediately  with  aircraft  passed  on  as  argument,  and 

•  trigger  UpdateFailedAir  craft  event  immediately  with 
aircraft  passed  on  as  argument. 

19. 

UpdateLandingSpot 

Does  nothing;  meant  to  be  heard  by  ShipServer  instances. 

20. 

UpdateFailedAir craft 

Does  nothing;  meant  to  be  heard  by  AircraftServer 
instances. 

21. 

FindReplacement 

Listens  to  ShipServer  instances  for  landing  spot  requiring  a 
replacement  aircraft  and  performs  one  of  the  following 
based  on  the  simulation  mode  selected: 

For  Replacement  Mode  #0  Scheme 

If  an  aircraft  is  found  in  the  holding  list  (Ah)  that  matches 
the  failed  aircraft  type  that  the  landing  spot  was  previously 
assigned  to, 

•  remove  it  from  the  list  and  set  the  time-out  for  its  entry 
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record  using  current  time, 

•  create  a  new  assignment  pairing  up  the  aircraft  and  the 
landing  spot  (that  is  already  loaded),  and  set  the  aircraft 
status  accordingly,  and 

•  trigger  UpdateReplacementAircraft  and 

StandbyLoading  events  immediately  with  the  aircraft 
and  landing  spot  passed  on  as  argument  respectively. 

If  there  is  no  matching  aircraft  in  Ah,  add  landing  spot  to 
the  replacement  list  (Lr). 

For  Replacement  Mode  #1  Scheme 

Add  the  load  transfer  amount  (as  stored  in  the  landing 
spot’s  assignment  record)  to  the  remaining  load  for  the 
affected  ship  (Qi|i])  as  well  as  the  fleet  (Q|i]),  and  trigger 
ResetLandingSpot  event  immediately  with  the  landing  spot 
passed  on  as  argument. 

22. 

ResetLandingSpot 

Does  nothing;  meant  to  be  heard  by  ShipServer  instances. 

23. 

StandbyLoading 

Does  nothing;  meant  to  be  heard  by  ShipServer  and 
AircraftServer  instances. 

Table  26.  Events  for  Scheduler  Component 


In  addition,  the  Scheduler  component  also  has  built-in  utilities  to  output  the  list  of 
assignments  and  the  holding  record  into  text  files  for  that  simulation  run.  One  can  then 
review  the  details  off-line  and  understand  how  the  operation  process  has  taken  place,  if 
required. 

6.  Recorder  Component 

This  is  more  of  a  peripheral  component  created  solely  for  recording  the  following 
runtime  data  for  each  simulation  run,  such  as: 

•  mission  completion  time,  defined  by  the  time  when  the  last  sortie  reaches 
the  target  site  to  complete  the  load  delivery,  and 

•  quantity  delivered  for  each  of  the  three  load  types  over  the  simulation 
duration  with  user-definable  interval  for  the  recording. 
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The  data  for  each  individual  run  is  then  collected  by  the  main  program  to  support 
the  post-simulation  statistical  analysis.  This  component  also  has  the  built-in  utility  to 
output  the  quantity  delivered  over  time  to  a  text  file.  The  following  figure  depicts  the 
component  event  graph  and  the  specific  events  are  described  in  Table  27. 


(i  <x- 1) 


{Tc  =  0, 

lc  =  0, 

Qt[1]  =  0, 
D[i]  =  0, 
D[1][t]  =  0  } 


{D[1][T]  -  D[i]} 


{  qp]  =  a.getAllocatedLoad(), 
Qt[1]  =  Qt[1]  +  q[i]} 


{1  =  c.getAssignment().getLoadType(),  {Tc  =  Schedule.getSimTime(), 

q  =  c.getAssignment().getLoadQuantity(),  Ic  =  1 } 

D[i]  =  D[i]  +  q} 


Figure  25.  Event  Graph  for  Recorder  Component 
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S/N 

Event 

Purpose 

1. 

Run 

Performs  the  following  at  the  start  of  the  simulation: 

•  initialize  delivery  completion  time  (Tc)  to  zero, 

•  initialize  delivery  completion  indicator  (Ic)  to  zero, 

•  initialize  total  quantity  for  load  type  1  (Qxpi)  to  zero, 

•  initialize  quantity  delivered  to  site  for  load  type  1  (Dm)  to 
zero,  and 

•  create  a  1  by  x  dimensional  array  for  recording  the  quantity 
delivered  for  each  load  type  1  (D|i|[t])  at  a  user-defined  time 
interval  (ti)  over  the  simulation  duration,  where  1  is  the 
number  of  load  types  and  x  is  the  number  of  intervals. 
Initialize  the  value  for  each  array  element  to  zero,  and 

•  triggers  MeasureLoad  event  immediately  with  zero  passed 
on  as  argument,  i.e.,  the  counter  used  for  looping  the  event. 

2. 

CreateShip 

Listens  to  ShipServer  instances  for  newly  created  ship  entity 
and  adds  its  load  quantity  to  total  load  (Qxii])- 

3. 

MeasureLoad 

Updates  the  appropriate  entry  for  the  load  quantity  delivered 
(D[i][t])  at  that  instance,  increase  the  counter  by  one,  and 
triggers  itself  after  ti  time  delay  with  the  counter  passed  on  as 
argument  for  (x  -  1)  times. 

4. 

ReachTarget 

Listens  to  AircraftServer  instances  for  the  delivery  aircraft  and 
increases  the  load  quantity  delivered  (D|i|)  by  the  load  transfer 
amount  as  stored  in  the  aircraft’s  assignment  record. 

Triggers  CompleteDelivery  event  immediately  if  all  loads  have 
been  delivered,  by  comparing  the  values  between  (Dm)  and 
(Qt[I|)- 

5. 

CompleteDelivery 

Sets  the  delivery  completion  time  (Qxm)  and  delivery 
completion  indicator  (Ic). 

Table  27.  Events  for  Recorder  Component 
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V.  TESTING  AND  EVALUATION 


A.  OVERVIEW 

The  testing  of  the  final  airlift  model  was  conducted  in  two  parts.  First  of  all,  the 
final  model  was  tested  against  the  verified  baseline  model  to  ensure  that  it  can  produce 
consistent  results  when  using  the  same  input  parameters  under  a  deterministic  setting. 
The  testing  then  focused  on  the  general  event  flow  and  the  variable  timing  parameters  to 
verify  that  the  simulated  airlift  process  abides  with  the  paper’s  design. 

B.  VERIFICATION  AGAINST  BASELINE  MODEL 
1.  Objective 

The  objective  was  to  verify  that  the  final  airlift  model  will  generate  the  same  load 
transfer  capabilities  and  the  sorties  as  the  baseline  model  for  the  three  Civil  Support 
mission  scenarios  and  the  respective  force  structures,  such  as  those  performed  in  Chapter 
111  and  summarized  in  the  following  table. 


S/N 

Scenario 

Scenario  Severity 

Low 

Mean 

High 

A. 

Load  Transfer  Capability  based  on  Baseline  Airlift  Model 

1. 

For  Cargo  (lbs) 

2,286,000 

729,000 

1,318,500 

2. 

For  Equipment  (sets) 

6 

11 

16 

3. 

For  Personnel  (pax) 

32 

72 

99 

B. 

Number  of  Delivery  Sorties 

4. 

For  CH-53 

67 

30 

56 

5. 

For  SH-60 

115 

24 

14 

C. 

Aircraft  Quantity  (i.e.,  the  force  structure) 

6. 

For  CH-53  (ea) 

1 

2 

7 

7. 

For  SH-60  (ea) 

2 

2 

2 

Table  28.  Test  Cases  for  Final  Airlift  Model  against  Baseline  Model 
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2.  Approach 

A  similar  approach  on  how  the  baseline  model  was  verified  against  Project  SEA- 
15  findings  was  adopted.  The  same  input  parameters  for  the  baseline  airlift  model  were 
used  for  the  final  model  in  order  for  it  to  generate  a  deterministic  output  for  comparison 
with  the  baseline  model.  The  following  are  the  main  settings  used  for  the  final  model: 

•  a  single  ship  was  modeled  to  supply  all  the  required  loads  with  a  high 
number  of  logistics  crew  and  landing  spots  (400  each), 

•  average  time  values  were  used  for  the  loading,  unloading,  delivery  and 
recovery  phase  (based  on  baseline  model  inputs),  with  the  loading  time  set 
to  zero, 

•  the  endurance  distance  (without  refueling)  and  the  time-to-failure  for  the 
aircraft  and  were  set  to  high  values  (10,000  nm  and  10,000  hr  respectively) 
to  negate  the  need  for  refuel  and  repair,  and 

•  reduced  operating  duration  (7.65  hr  based  on  baseline  model  input)  to 
account  for  the  time  spent  for  refuel  and  repair. 

Given  that  the  final  model  can  generate  the  list  of  conducted  sorties  with  the 
involved  timings,  the  approach  was  to  inject  a  higher  load  transfer  capability  value  (i.e., 
for  cargo  load  type)  as  input  to  the  model,  so  as  to  show  the  last  sortie  that  can  be 
completed  within  the  mission  time  and  the  remaining  load  at  that  juncture.  In  this  case, 
the  quantity  set  was  set  just  one  more  than  the  load  transfer  capability,  i.e.,  2,286,001, 
729,001  and  1,318,501  lbs  for  the  low,  mean  and  high  severity  scenarios  respectively. 

2.  Test  Results 

For  all  the  three  tested  scenarios,  the  final  airlift  model  generated  the  same  load 
transfer  capabilities  and  the  required  sorties  as  per  the  baseline  model.  The  following  is 
the  extract  of  the  model  output  for  the  high  severity  scenario  test  case,  which  showed  that 
the  70*  sortie  was  the  last  one  that  could  be  completed  within  the  mission  time  (before 
459  min,  the  equivalent  of  7.65  hr),  and  the  remaining  load  at  that  instance  was  one 
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pound  of  cargo,  the  expected  “right”  answer  for  the  testing.  Refer  to  Appendix  B  for  the 
complete  model  output  fdes  for  the  three  test  scenarios. 


Assign# 

Aircraft# 

Load 

Type# 

Transfer 

Qty 

Start 

Loading 

Time 

Start 

Sortie 

Time 

Reach 

Target 

Time 

Leave 

Target 

Time 

End 

Sortie 

Time 

Cargo 

Left 

Eqpt 

Left 

Passenger 

Left 

#1 

CH53#0 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

14 

99 

#2 

CH53#1 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

12 

99 

#3 

CH53#2 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

10 

99 

#4 

CH53#3 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

8 

99 

#5 

CH53#4 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

6 

99 

#6 

CH53#5 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

4 

99 

#7 

CH53#6 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

2 

99 

#68 

CH53#4 

0 

27000 

380.88 

381.88 

414.88 

415.88 

435.29 

54001 

0 

0 

#69 

CH53#5 

0 

27000 

380.88 

381.88 

414.88 

415.88 

435.29 

27001 

0 

0 

#70 

CH53#6 

0 

27000 

380.88 

381.88 

414.88 

415.88 

435.29 

1 

0 

0 

#71 

SH60#0 

0 

1 

405.89 

406.89 

448.14 

449.14 

471.59 

0 

0 

0 

Figure  26.  Extract  of  the  Final  Airlift  Model  Output  for  High  Severity  Scenario 

Test  Case 


C.  VERIFICATION  FOR  GENERAL  EVENT  FLOW  AND  TIMING 

PARAMETERS 

1.  Objective 

The  testing  was  to  verify  that  the  general  event  flow  and  the  variable  timing 
parameters  of  the  simulated  airlift  processes  are  in  accordance  with  the  paper  design,  i.e., 
based  on  the  event  graphs  and  the  inputs  parameters  used. 

2.  Approach 

A  straightforward  testing  approach  was  adopted  by  running  the  model  with  a  set 
of  input  parameters  and  then  verifying  the  output  results  using  the  verbose  mode  and  the 
other  generated  files  (similar  to  the  one  presented  earlier)  to  ensure  that  the  logged  events 
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have  occurred  in  proper  sequence  and  are  reflective  of  the  inputs  used.  In  this  case, 
uniform  distribution  was  used  for  all  random  timing  variates  to  facilitate  verification.  For 
each  set  of  input  parameters  tested,  multiple  runs  (i.e.,  1,000)  were  conducted  to  verify 
that  the  random  variates  used  would  inject  stochasticity  into  the  simulation  as  well  as  sift 
out  any  latent  anomalies  that  may  not  surface  within  a  single  run. 

3.  Results 

The  model  was  tested  against  ten  sets  of  different  input  parameters.  The 
generated  event  flows  and  timings  were  found  to  be  consistent  with  the  design  and  input 
parameters. 

The  verification  scope  was  by  no  means  comprehensive,  given  the  number  of 
parameters  and  their  ranges  that  can  be  varied  to  meet  different  simulation  needs.  For  the 
purpose  of  this  thesis  work,  the  verification  conducted  and  the  test  results  shown  were 
deemed  adequate  to  move  on  and  experiment  with  the  model’s  capability. 
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VI.  DESIGN  OF  EXPERIMENT 


A.  OVERVIEW 

Three  sets  of  experiments  were  conducted.  The  first  experiment  was  designed  to 
demonstrate  the  final  airlift  model’s  ability  to  meet  the  objectives  set  for  this  thesis  work 
with  the  next  experiment  to  illustrate  the  difference  in  the  outcomes  (if  any)  of  using  the 
various  simulation  schemes  implemented  in  the  model.  The  last  experiment  was 
conducted  to  compare  the  load  transfer  capability  computed  by  the  final  and  baseline 
airlift  models. 

B.  EXPERIMENT  #1  -  GENERAL  PERFORMANCE  MEASURES 

1.  Objectives 

The  experiment  was  designed  to  demonstrate  that  the  final  airlift  model  can 
support  the  list  of  performance  measures  established  under  Chapter  II  for  assessing  the 
airlift  operation  effectiveness  and  its  workflow  efficiency. 

2.  Experiment  Setting  and  Input  Parameters 

The  high  severity  scenario  defined  for  the  Civil  Support  mission  was  used  as  the 
backdrop  for  the  experiment  to  assess  the  airlift  operation  performance  of  the 
recommended  Phase  Zero  force.  In  a  nutshell,  three  ships,  i.e.,  JMSDF,  LPD-17  and 
JHSV  with  seven  CH-53  and  two  SH-60  are  required  to  airlift  1,238,200  lbs  of  cargo,  16 
sets  of  equipment  and  99  passengers  to  an  affected  area  that  is  55  nm  away  from  the  ships 
within  the  mission  day  (i.e.,  12-hour  operation  day).  The  input  parameters  adopted  those 
used  or  referenced  in  Project  SEA- 15  or  otherwise,  were  based  on  notional  values.  Refer 
to  Appendix  C  for  the  model  input  parameters  defined  for  this  experiment. 

The  airlift  model  was  run  1 ,000  times  to  gather  a  good  statistical  estimate  for  the 
performance  measures. 
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3. 


Simulation  Outcome 


The  main  performance  measures  captured  for  the  simulation  are  summarized  in 
the  following  table. 


S/N 

Parameters 

Value 

A. 

Overall  Measures 

1. 

Average  cargo  delivered  (lbs) 

1,238,200  (100%) 

2. 

Average  equipment  delivered  (sets) 

16  (100%) 

3. 

Average  passengers  delivered  (pax) 

99  (100%) 

4. 

Average  time  to  complete  delivery  (hrs) 

8.11  hrs 

5. 

Minimum  time  to  complete  delivery  (hrs) 

7.24  hrs 

6. 

Maximum  time  to  complete  delivery  (hrs) 

10.45  hrs 

7. 

Standard  deviation  for  delivery  time  (hrs) 

0.48  hrs 

8. 

Number  of  completed  delivery 

1000  (100%) 

B. 

Ship-related  Measures 

JMSDF 

LPD-17 

JHSV 

9. 

Average  cargo  remaining  (lbs) 

0 

0 

0 

10. 

Average  equipment  remaining  (sets) 

0 

0 

0 

11. 

Average  passengers  remaining  (pax) 

0 

0 

0 

12. 

Crew  utilization 

16.39% 

22.12% 

26.41% 

13. 

Landing  spots  utilization 

71.96% 

63.43% 

58.89% 

•  Active  preparation/loading  activities 

16.39% 

22.12% 

26.41% 

•  Standby  for  load-up 

13.58% 

16.62% 

24.69% 

•  Service  support 

41.98% 

24.69% 

6.30% 

C. 

Aircraft-related  Measures 

CH-53 

SH-60 

14. 

Average  cargo  delivered  (lbs) 

1,209,669  (97.7%) 

28,531  (2.3%) 

15. 

Average  equipment  delivered  (sets) 

16  (100%) 

0  (0%) 

16. 

Average  passengers  delivered  (pax) 

6.9  (7%) 

92.1  (93%) 

17. 

Average  sorties  flown 

54.7 

14.5 

18. 

Aircraft  utilization 

64.5% 

66.7% 
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S/N 

Parameters 

Value 

•  Waiting 

2.57% 

2.51% 

•  Loading 

1.13% 

3.25% 

•  Delivery 

35.70% 

30.90% 

•  Unloading 

1.13% 

3.26% 

•  Recovery 

21.08% 

22.71% 

•  Refuel 

1.77% 

1.20% 

•  Repair 

3.10% 

2.86% 

Table  29.  Performance  Measures  for  Final  Airlift  Operation  Model 


The  experiment  has  demonstrated  the  model’s  ability  to  support  the  defined 
performance  measures  for  operational/tactical  level  analysis  with  the  higher  resolution 
modeling  of  the  airlift  operation  process  using  DBS.  To  illustrate,  based  on  the 
assumptions  and  input  parameters  used,  the  model  suggested  that  the  recommended 
Phase  Zero  force  would  be  able  to  support  the  high  severity  scenario  with  the  following 
findings  that  can  be  drawn  from  the  data  collected: 

•  Mission  Completion  Time.  The  mission  duration,  on  average,  would  last 
for  8.1  hrs  with  95%  confidence  that  the  mission  can  be  completed  within 
8.9  hrs  based  on  the  standard  deviation  observed  (and  through  further 
statistical  analysis). 

•  Mission  Sorties.  It  would  take  about  70  sorties  to  complete  the  delivery 
where  each  CH-53  and  SH-60  aircraft  accounts  for  7.8  and  7.25  sorties  on 
average  respectively.  In  this  case,  the  higher  sortie  rate  for  CH-53  is 
largely  attributed  to  its  faster  airspeed. 

•  Aircraft  Utilization.  The  CH-53  and  SH-60  aircraft  would  be  utilized 
about  two-thirds  of  the  time,  on  average.  There  would  be  some  waiting 
expected  for  the  required  resources  to  execute  the  load-up  and/or  provide 
the  service  support  at  times.  Longer  loading/unloading  time  for  SH-60 
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aircraft  would  also  be  expected  by  virtue  of  the  faet  that  it  will  be  used 
more  often  for  transporting  passengers,  due  to  its  relative  advantage  in 
doing  so  as  discussed  earlier. 

•  Landing  Spot  Utilization.  The  utilization  rate  is  dependent  upon  the 
amount  of  loads  and  the  number  of  landing  spots  onboard  the  ship.  The 
gathered  data  ean  faeilitate  the  planning  of  the  load  distribution  based  on 
the  resources  available  for  each  ship.  For  this  experiment,  the  load 
distribution  seemed  reasonable,  with  an  overall  utilization  rate  differenee 
of  less  than  10%  off  the  average.  The  higher  usage  rates  for  serviee 
support  observed  for  JMSDF  and  LPD-17  are  because  more  landing  spots 
were  set  aside  for  that  purpose,  especially  for  the  JMSDF.  For  JHSV, 
there  is  only  one  landing  spot  and  it  was  therefore  set  up  to  do  load 
transfer  full  time  until  all  the  loads  had  been  transferred,  before  providing 
serviee  support. 

•  Crew  Utilization.  Similarly,  erew  utilization  is  dependent  upon  the 
amount  of  loads  to  be  transferred  and  in  this  case,  the  JHSV  has  a  higher 
utilization  for  the  reason  cited  above. 

•  Duration  of  Aireraft  in  Various  Operation  Phases.  The  gathered  data 
provided  an  indication  of  the  expeeted  time  spent  for  eaeh  aircraft  type  in 
eaeh  of  the  operation  phases.  With  good  data  on  the  mean-time-between- 
failure  (MTBF)  and  mean-time-to-repair  (MTTR)  for  the  aireraft,  the 
simulation  would  be  able  to  provide  a  good  indication  on  the  overall  Ao  for 
the  aircraft  fleet  based  on  the  ship  resource  support/constraint. 

•  Load  Delivered  Over  Time.  In  order  to  determine  the  load  “arrival”  rates, 
at  the  target  site,  for  planning  the  supporting  and  follow-on  ground 
aetivities,  the  model  also  generates  the  transferred  load  quantity  over  the 
mission  duration  based  on  the  timing  resolution  that  one  is  interested  in 
monitoring.  The  following  figure  is  the  load-versus-time  graph  plotted. 
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based  on  the  data  collected  for  experiment.  In  this  case,  the  time  interval 
was  set  at  six  minutes,  and  the  delivered  quantity  presented  in  percentages, 
with  reference  to  load  transfer  requirements. 
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C.  EXPERIMENT  #2  -  COMPARISON  OF  SIMULATION  SCHEMES 
1.  Objectives 


The  experiment  was  designed  to  compare  the  simulation  outcomes  of  using  the 
different  load  allocation  and  landing  spot  reassignment  schemes  that  were  implemented 
in  the  model.  To  recap,  the  available  modes  are 


•  Load  Allocation  Mode  #0  (LAM#0).  The  load  allocation  is  optimised  at 
the  ship-level. 

•  Load  Allocation  Mode  #1  (LAM#1).  The  load  allocation  optimization  is 
attempted  at  the  fleet-level  based  on  a  longer  waiting  time  (set  as  five 
minutes)  that  one  is  willing  to  accept  in  order  to  get  a  better  load-aircraft 
match,  based  on  the  list  of  aircraft  that  have  requested  assignments  at  the 
juncture. 

•  Landing  Spot  Reassignment  Mode  #0  (LRM#0).  This  is  the  substitution 
mode  whereby  the  landing  spot  with  assigned  aircraft  that  have  failed  will 
find  the  next  available  replacement  of  the  same  aircraft  type  to  takeover 
the  prepared  load. 

•  Landing  Spot  Reassignment  Mode  #1  fLRM#l).  This  is  the  reset  mode 
whereby  the  landing  spot  will  “return”  the  prepared  load  and  check  for  the 
next  task  instead. 


2.  Experiment  Setting  and  Input  Parameters 

The  same  high  severity  scenario  and  input  parameters  were  used  as  baselines  for 
this  experiment,  except  for  the  load  allocation  and  landing  spot  reassignment  modes 
selected.  Four  sets  of  scenarios  were  simulated  using  the  different  combinations  for  the 
two  modes  available.  Each  set  of  scenarios  was  run  1,000  times  to  gather  a  good  sample 
size  for  comparison. 
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3. 


Simulation  Outcome 


All  loads  can  be  delivered  within  the  mission  time  for  the  all  schemes 
implemented.  The  following  table  summarizes  the  key  performance  measures  recorded 
for  these  four  sets  of  simulated  scenarios. 


Parameters 

LAM#0 

LAM#1 

LRM#0 

LRM#1 

LRM#0 

LRM#1 

Overall  Parameters 

Average  time  to  complete 
delivery  (hrs) 

8.15 

8.13 

8.11 

8.11 

Minimum  time  to  complete 
delivery  (hrs) 

7.25 

7.18 

7.17 

7.24 

Maximum  time  to  complete 
delivery  (hrs) 

11.61 

11.38 

10.84 

10.45 

Standard  deviation  for  delivery 
time  (hrs) 

0.53 

0.50 

0.48 

0.48 

Ship-related  Measures 

Average  crew  utilization 

20.95% 

21.39% 

21.17% 

21.64% 

Average  landing  spots  utilization 

64.69% 

64.94% 

64.67% 

64.48% 

•  Active  preparation/loading 
activities 

20.95% 

21.39% 

21.17% 

21.64% 

•  Standby  for  load-up 

19.16% 

18.46% 

19.36% 

18.79% 

•  Service  support 

24.52% 

25.09% 

24.10% 

24.33% 

Aircraft-related  Measures 

Cargo  delivered  by  CH-53  (lbs) 

1,208,066 

1,208,113 

1,210,103 

1,209,669 

Cargo  delivered  by  SH-60  (lbs) 

30,134 

30,087 

28,097 

28,531 

Equipment  delivered  by  CH-53 
(sets) 

16 

16 

16 

16 

Equipment  delivered  by  SH-60 
(sets) 

0 

0 

0 

0 

Passengers  delivered  by  CH-53 
(pax) 

12.33 

11.76 

6.696 

6.909 

Ill 


Parameters 

LAM#0 

LAM#1 

LRM#0 

LRM#1 

LRM#0 

LRM#1 

Passengers  delivered  by  SH-60 
(pax) 

86.67 

87.24 

92.304 

92.091 

Sorties  flown  by  CH-53 

54.93 

54.95 

54.72 

54.73 

Sorties  flown  by  SH-60 

14.19 

14.22 

14.38 

14.46 

Average  Aircraft  utilization 

67.27% 

66.70% 

67.18% 

66.59% 

•  Waiting 

3.16% 

2.59% 

3.14% 

2.54% 

•  Loading 

2.11% 

2.11% 

2.19% 

2.19% 

•  Delivery 

33.36% 

33.38% 

33.18% 

33.30% 

•  Unloading 

2.11% 

2.11% 

2.19% 

2.19% 

•  Recovery 

21.72% 

21.74% 

21.82% 

21.90% 

•  Refuel 

1.46% 

1.47% 

1.49% 

1.49% 

•  Repair 

3.37% 

3.29% 

3.17% 

2.98% 

Table  30.  Comparison  Between  Different  Simulation  Schemes  Implemented  in  Final  Airlift 

Model 

Based  on  the  gathered  data,  the  average  and  maximum  delivery  completion  times 
for  both  scenarios,  using  the  fleet-level  load  allocation  (i.e.,  LAM#1)  were  shorter,  but  of 
no  significant  difference.  In  fact,  the  overall  performance  profiles  for  the  task  force 
under  these  various  schemes  were  found  to  be  very  similar  except  for  the  specific  areas 
where  the  implemented  schemes  have  a  direct  effect.  Under  the  fleet-level  load 
allocation  scheme,  there  was  a  better  load-aircraft  match  observed  than  expected,  with 
more  than  a  5%  increase  in  passengers  being  transported  by  SH-60  aircraft.  As  for  the 
landing  spot  reassignment  scheme,  the  landing  spot  usage  for  preparation/loading 
activities  was  observed  to  be  slightly  higher  and  correspondingly  less  time  was  spent 
standing-by  for  aircraft  under  both  scenarios  using  the  reset  approach  (i.e.,  LRM#1), 
which  is  to  be  expected.  However,  the  secondary  effect  on  the  waiting  time,  which  was 
found  to  be  shorter  (i.e.,  >20%),  under  the  reset  approach,  was  not  something  perceivable 
at  the  design  stage. 
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D.  EXPERIMENT  #3  -  LOAD  TRANSFER  CAPABILITY 


1.  Objectives 

The  experiment  was  conducted  to  assess  the  load  transfer  capability  of  the  Phase 
Zero  task  force  to  support  the  high  severity  scenario  based  on  the  stochastic  approach, 
using  the  final  airlift  model,  and  compare  the  results  from  the  baseline  model,  which  was 
deterministic  based. 

2.  Experiment  Setting  and  Input  Parameters 

The  scenario  input  parameters  were  the  same  as  those  used  for  the  first 
experiment,  except  that  the  cargo  load  quantity  was  increased  to  2.5M  lbs  as  a  “goal”  to 
assess  how  much  the  task  force  could  transfer  within  the  12-hour  mission  day.  Transfer 
capability  for  cargo  load  type  was  used  for  the  experiment  because  it  was  the  benchmark 
adopted  by  Project  SEA- 15  for  the  same  purpose. 

3.  Simulation  Outcome 

The  performance  measures  captured  for  the  simulation  are  summarized  in  the 
following  table  with  the  “load  delivered  over  time”  graph  depicted  in  Figure  28. 


S/N 

Parameters 

Value 

A. 

Overall  Measures 

Min 

Mean 

Max 

1. 

Cargo  delivered  (lbs) 

1,697,000 

2,049,000 

2,242,000 

2. 

Equipment  delivered  (sets) 

16 

16 

16 

3. 

Passengers  delivered  (pax) 

96 

99 

99 

B. 

Ship-related  Measures 

JMSDF 

LPD-17 

JHSV 

4. 

Cargo  allocated  (lbs) 

1,000,000 

1,000,000 

500,000 

5. 

Cargo  remaining  (lbs) 

11,526 

283,438 

7,974 

6. 

Equipment  allocated  (sets) 

6 

6 

4 

7. 

Equipment  remaining  (sets) 

0 

0 

0 

8. 

Passengers  allocated  (pax) 

63 

24 

12 

9. 

Passengers  remaining  (pax) 

0 

0 

0 
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S/N 

Parameters 

Value 

10. 

Crew  utilization 

25.50% 

36.63% 

52.71% 

11. 

Landing  spots  utilization 

94.03% 

96.79% 

97.11% 

•  Active  preparation/loading  activities 

25.50% 

36.63% 

52.71% 

•  Standby  for  load-up 

22.23% 

26.68% 

40.68% 

•  Service  support 

46.30% 

40.68% 

3.72% 

c. 

Aircraft-related  Measures 

CH-53 

SH-60 

12. 

Average  cargo  delivered  (lbs) 

1,994,291 

54,340 

13. 

Average  equipment  delivered  (sets) 

16 

0 

14. 

Average  passengers  delivered  (pax) 

0 

99 

15. 

Average  sorties  flown 

86.0 

22.2 

16. 

Aircraft  utilization 

99.70% 

99.53% 

•  Waiting 

3.34% 

2.90% 

•  Loading 

1.17% 

4.04% 

•  Delivery 

55.13% 

50.32% 

•  Unloading 

1.63% 

3.96% 

•  Recovery 

31.29% 

32.69% 

•  Refuel 

2.63% 

1.67% 

•  Repair 

3.97% 

3.95% 

Table  3 1 .  Load  Transfer  Capability  for  High  Severity  Scenario  based  on  Final  Airlift  Model 

The  data  gathered  from  the  final  airlift  model  suggested  that  the  load  transfer 
capability  for  Phase  Zero  force  is,  on  average,  about  two  million  lbs  for  cargo.  It  met  the 
equipment  and  passengers  transfer  requirements  on  most  occasions,  except  for  one 
instance  where  an  additional  sortie  was  required  to  complete  passenger  delivery.  If  this  is 
disregarded,  there  is  95%  confidence  that  the  task  force  can  deliver  2.18M  lbs  of  cargo 
based  on  the  observed  standard  of  about  80K  lbs. 
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Tune  (in  hours) 


Figure  28.  Load  Transfer  Capability  over  Time  for  High  Severity  Scenario  based  on 

Final  Airlift  Model 


The  average  load  transfer  capability,  based  on  this  final  airlift  model,  is 
substantially  higher  (>65%)  than  that  obtained  from  the  baseline  model,  i.e.,  1,318,500 
lbs.  This  vast  difference  is  largely  attributed  to  the  assumptions  made  in  deriving  the 
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effective  operating  hours.  For  the  baseline  model  (and  in  the  case  of  Project  SEA-15),  a 
three-hour  block  was  set  aside  for  refueling  and  other  overheads  with  the  further 
assumption  of  an  85%  Ao,  which  resulted  in  the  7.65  effective  operating  hours  for  the 
mission  day.  For  the  final  model,  the  settings  for  the  meantime  for  refueling  was  five 
minutes,  meantime  for  preparing  cargo/equipment  at  15  minutes  and  for  passengers  at 
five  minutes,  with  MTBF  and  MTTR  at  20-hours  and  1-hour  respectively  (giving  an 
equivalent  Ao  of  about  95.2%)  for  both  aircraft  types.  Based  on  the  gathered  aircraft 
utilization  data  in  Table  31,  the  equivalent  effective  operating  hours  can  be  approximated 
by  discounting  the  average  time  spent  for  each  aircraft  in  the  waiting,  refueling  and  repair 
phases.  This  value  worked  out  to  be  10.85  hours,  i.e.,  at  least  three  hours  more  than  what 
the  other  approach  used. 

To  further  illustrate  the  Ao  impact  on  the  load  transfer  capability,  additional 
simulations  were  conducted  with  MTBF  inputs  ranging  between  10  to  20  hours  using  a 
2. 5 -hour  time  block  and  MTTR  inputs  between  one  to  three  hours  with  a  1-hour  time 
block.  Table  32  summarizes  the  computed  Ao  (based  on  MTBF  and  MTTR),  observed 
effective  operating  hours,  and  the  average  load  transfer  capability  for  cargo  for  each  of 
the  scenarios  (with  1,000  simulation  runs  each).  Again,  for  most  of  the  simulation  runs, 
the  delivery  of  passengers  and  equipment  were  complete.  Figure  29  depicts  the  average 
load  transfer  capability  trend  over  the  tested  ranges  for  MTTR  and  MTBF  using  linear 
interpolation  based  on  the  sampled  points. 
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MTBF 

(hr) 

MTTR 

(hr) 

A„ 

Effective  Operating 
Hours  (hr) 

Transfer  Capability  for 
Cargo  (lbs) 

10 

1 

0.91 

10.31 

1,932,883 

10 

2 

0.83 

9.64 

1,777,221 

10 

3 

0.77 

9.21 

1,681,635 

12.5 

1 

0.93 

10.65 

1,974,621 

12.5 

2 

0.86 

10.15 

1,898,456 

12.5 

3 

0.81 

9.78 

1,815,096 

15 

1 

0.94 

10.65 

2,006,324 

15 

2 

0.88 

10.15 

1,898,456 

15 

3 

0.83 

9.78 

1,815,096 

17.5 

1 

0.95 

10.76 

2,027,820 

17.5 

2 

0.90 

10.32 

1,932,200 

17.5 

3 

0.85 

10.02 

1,867,651 

20 

1 

0.95 

10.85 

2,048,631 

20 

2 

0.91 

10.47 

1,968,564 

20 

3 

0.87 

10.16 

1,899,240 

Table  32.  Operational  Availability  Impact  on  Load  Transfer  Capability  for  High  Severity 

Scenario  based  on  Final  Airlift  Model 
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Figure  29.  MTTR  and  MTBF  impacts  on  Load  Transfer  Capability  for  High  Severity 

Scenario  based  on  Final  Airlift  Model 

The  simulation  results  still  show  a  higher  load  transfer  capability  for  the  task 
force  versus  the  deterministic  approach  for  MTTR  and  MTBF  ranges  tested.  For  the 
“worst-case”  scenario,  with  MTBF  and  MTTR  set  at  10-hours  and  3 -hours  respectively, 
i.e.,  giving  a  lower  77%  Aq  than  the  85%  used  for  the  baseline  model,  the  average  load 
transfer  capability  is  still  higher,  at  about  1.68M  lbs  and  27%  more  than  the  deterministic 
value. 
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VII.  CONCLUSION 


A.  CONCLUSION 

The  objectives  of  this  thesis  were  achieved  with  the  successful  implementation  of 
a  stochastic,  dynamic  model  using  DBS  that  can  be  used  to  analyze  the  airlift  operation 
performance  of  the  naval  force  structure  recommended  by  Project  SEA- 15  at  the 
operational/tactical  level. 

An  iterative  development  approach  was  adopted  to  allow  a  baseline  model  to  be 
developed  quickly  in  the  early  study  phase,  which  demonstrated  the  feasibility  of  using 
DBS  to  address  the  issues  under  study.  The  simulated  results  from  the  constructed 
baseline  model  were  compared  with  Project  SEA- 15  findings,  which  sifted  out  some 
inconsistencies  in  the  latter’s  reported  data.  Mathematical  and  linear  optimization 
analyses  were  conducted  as  part  of  the  verification  process.  The  baseline  model  was 
subsequently  used  to  generate  the  load  transfer  capability  of  the  Phase  Zero  force,  based 
on  the  same  deterministic  input  parameters  used  by  the  project  to  serve  as  a  proxy  for 
comparison  with  the  final  model.  The  airlift  operation  was  abstracted  in  the  final  model 
as  a  six-phase  stochastic  process  with  a  scheduler  responsible  for  planning  and 
coordinating  the  activities  involved 

Three  sets  of  experiments  were  conducted,  with  the  first  one  set  up  to  demonstrate 
the  final  airlift  model’s  ability  to  meet  the  performance  measures  using  the  high  severity 
scenario  requirement  as  the  case  study.  The  experiment  showed  that  the  airlift  mission 
could  be  accomplished  within  nine  hours,  with  more  than  95%  confidence,  and  utilizing 
about  66%  of  the  airlift  fleet  capacity  for  a  mission  day.  Further  experiments  were 
conducted  to  assess  the  effectiveness  of  the  different  load  allocation  and  landing  spot 
reassignment  (in  the  event  of  an  assigned  aircraft  failure)  schemes  implemented  in  the 
model,  and  there  were  no  significant  performance  differences  observed.  The  final 
experiment,  using  the  final  airlift  model  (i.e.,  with  stochastic  data),  suggested  a  much 
higher  load  transfer  capability  (>60%)  for  the  Phase  Zero  force  as  compared  to  the 
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baseline  model,  which  was  deterministic  based.  Further  data  were  also  collected  to 
illustrate  the  collective  impact  of  the  aircraft  MTBF  and  MTTR  on  the  Phase  Zero  force’s 
load  transfer  capability. 

B.  RECOMMENDATIONS  AND  EUTURE  WORK 

This  thesis  work  has  demonstrated  the  model’s  potential  in  assessing  the  Phase 
Zero  force’s  airlift  capability  by  providing  operational/tactical  level  insights  to  the 
operation  process.  It  should  be  considered  for  supporting  future  analysis  work  for  the 
Phase  Zero  force  if  the  stakeholders  intend  to  bring  the  project  to  the  next  phase. 

The  model  was  developed  primarily  as  a  proof-of-concept,  and  as  such,  it  did  not 
cover  all  aspects  of  the  airlift  operation  and/or  the  depths  necessary  to  support  full 
analysis  work.  With  the  Phase  Zero  force  being  the  primary  design  focus,  some  aspects 
of  the  model  were  implemented  specifically  (e.g.,  hard-coded)  to  that  task  force.  Hence, 
its  immediate  use  for  supporting  other  analysis  work  of  a  similar  nature  is  limited. 
However,  with  the  component-based  framework  adopted  for  the  model,  components  can 
be  readily  added  /replaced  to  expand  the  modeling  scope  or  enhance  the  model  fidelity  to 
address  these  needs,  as  and  when  required.  The  following  are  possible  future 
enhancements  of  the  model’s  capability: 

•  There  were  no  intermediate  delivery  requirements/conditions  simulated  in 
the  model,  e.g.,  the  different  load  types  must  be  delivered  in  sequence,  or 
50%  of  the  equipment  must  be  delivered  first,  before  passengers  can  be 
delivered,  etc.,  because  there  were  no  specifications  for  that  based  on  the 
Project  SEA- 15  report.  The  model  currently  allocates  the  load  based  on 
what  the  aircraft  is  best  suited  for,  which  is  reasonable,  but  there  may  be 
other  overarching  requirements,  at  times,  that  need  to  supersede  that. 
Incorporating  a  utility  to  handle  these  additional  delivery  conditions  will 
improve  the  model’s  robustness. 

•  The  maintenance  and  logistics  support  for  the  aircraft,  in  terms  of  the 
required  repair/refueling  facilities  and  support  crew,  were  not  explicitly 
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modeled.  Modeling  these  elements  would  provide  more  complete 
shipboard  operation  coverage  and  assess  its  impact  on  the  airlift  capability. 

•  The  load  delivery  was  modeled  one-way,  i.e.,  from  the  ship  to  the  affected 
area,  based  on  the  mission  scenarios  defined  for  Phase  Zero  force. 
Expanding  the  model  to  cater  to  two-way  delivery  would  be  useful  given 
that  relief  missions  would  include  the  need  to  evacuate  affected  personnel 
from  disaster-hit  sites. 

•  The  airlift  operation  was  modeled  as  a  single  continuous  process  (per 
simulation  run),  meant  for  analyzing  the  performance  for  a  single-day  (in 
the  case  of  Project  SEA- 15)  or  24/7  type  of  missions.  Expanding  the 
model’s  capability  to  simulate  the  operation  as  a  “piecewise”  continuous 
process,  by  retaining  certain  entities’  state  information  at  the  break-points, 
would  enable  it  to  better  mimic  non-continuous  multi-day  missions  (e.g., 
simulating  daylight  operation  only). 

•  The  setting  up  of  a  scenario  is  currently  done  within  the  NetBeans  IDE  and 
the  interface  may  not  necessarily  be  intuitive  to  a  non-programmer. 
Providing  a  user-friendly  front-end  user  interface  would  help  to  improve 
its  usability. 

•  Parameterize  or  encapsulate  the  platform- specific  built-in  (hardcoded) 
logics  into  subcomponents  to  generalize  the  model  so  that  it  could  be  used 
to  support  other  force  structure  studies  as  well. 
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APPENDIX  A.  PLATFORM  CAPABILITIES 


The  capabilities  for  the  various  platforms  are  based  on  the  data  sheets  compiled  in 
the  Project  SEA- 15  report  [1]  except  for  the  JMSDF  DDH  class  destroyer  and  RQ-8 
Firescout,  which  the  cited  report  did  not  have  the  data  sheet  for,  and  in  this  case,  the  open 
source  data  is  used. 


A.  JMSDF  DDH  CLASS  DESTROYER 


S/N 

Parameters 

Description 

1. 

Displacement  (tonnes) 

13,500  standard;  18,000  full  load 

2. 

Dimensions  (ft) 

646.3  X  108.3  X31.8 

3. 

Main  machinery 

COGAG;  four  EM  2500  gas  turbines;  two  shafts 

4. 

Speed  (knts) 

30 

5. 

Range  (nm) 

6,000  at  20  kt 

6. 

Missiles 

Raytheon  Sea  Sparrow  RIM- 162  ESSM;  Lockheed 
Martin  Marietta  Mk  41  Mod  5  sixteen  cell  vertical 
launcher 

7. 

Guns 

Two  GE  20  mm/76  Sea  Vulcan  20,  2-12.7  mm 

MGs 

8. 

Torpedoes: 

6-324  mm  (2  triple)  HOS-303  tubes 

9. 

Countermeasures:  Decoys: 

4  Hycor  Mk  137  sextuple  RBOC  chaff  launchers. 

10. 

Electronics  Support 

Measures  /  Electronic 
Countermeasures : 

NOLQ-3C 

11. 

Combat  Data  Systems: 

Link  16 

12. 

Radars 

Melco  FCS-3;  G/H/I-band 

13. 

Navigation 

JRC  OPS-20C;  I-band. 

14. 

Sonars 

Bow-mounted  sonar.  OQQ  21. 

15. 

Organic  Aircraft 

Three  SH-60K  plus  seven  SH-60K  or  seven  MCH- 
101. 

Table  33.  Data  Sheet  for  JMSDF  DDH  (after  [18]) 
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B.  LPD-17  CLASS  AMPHIBIOUS  ASSAULT  SUPPORT  VESSEL 


S/N 

Parameters 

Description 

1. 

Displacement  (tonnes) 

24,900 

2. 

Draft  (ft) 

23 

3. 

Endurance  (nm) 

8,000 

4. 

Speed  (knts) 

25 

5. 

Officers 

24 

6. 

Enlisted 

333 

7. 

Troops 

720 

8. 

Organic  Boats 

Two  LCPL,  one  RHIB  (7m),  one  utility  boat 

9. 

Well  Deck  Capability 

188ft  long  x50ft  wide  x  31ft  high 

Two  LCAC,  or  one  LCU  1610  plus  14  EFV 

10. 

Cargo  Capacity  (ft^) 

30,000 

11. 

Vehicle  Space  (ft^) 

25,000 

12. 

Water  Purification  capability 
(gal/day) 

60,000 

13. 

Helo  Capable 

Yes 

14. 

Help  Spots 

Two  CH-53  Spot/  Six  extended  spots 

15. 

Organic  Aircraft 

Two  CH-53S,  or  Four  AH/UH-ls,  or  Four  CH-46s, 
or  Two  MV-22s,  or  One  AV-8B  Harrier 

16. 

Operating  Rooms 

Two 

17. 

Beds 

24  Bed  Ward 

18. 

Dental  Facilities 

Yes 

19. 

Self  Defense  Weapons 

Two  MK-49  RAM,  two  MK-38  Bushmaster,  two 
MK-26  12.7mm  machine  guns 

20. 

Offensive  Weapons 

N/A 

21. 

Radar 

SPS-48E  Air  search,  SPS-73  Navigation/Surface 
search 

22. 

Sonar 

N/A 

23. 

Electronic  Warfare  /  Intel 

SLQ-32,  SLQ-25A,  SRS-1  Joint  Services  Imagery 
Processing  System-Navy  (JSIPS-N) 

24. 

Communications 

SHF,UHF,HF,VHF 

25. 

Command/Flag  Space 

N/A 

T able  34.  Data  Sheet  for  LPD- 1 7  (after  [  1  ]) 
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C.  JOINT  HIGH  SPEED  VESSEL  (JHSV) 


S/N 

Parameters 

Description 

1. 

Displacement  (tonnes) 

1463.6 

2. 

Draft  (ft) 

11 

3. 

Endurance  (nm) 

3,500 

4. 

Speed  (knts) 

45 

5. 

Crew 

40 

6. 

Troops 

107+87 

7. 

Organic  Boats 

Two  RHIB 

8. 

Well  Deck  Capability 

No 

9. 

CargoW chicle  Capacity  (ft^) 

28,740 

10. 

Helo  Capable 

Yes 

11. 

Help  Spots 

Two  (MH-60) 

12. 

Organic  Aircraft 

N/A 

13. 

Operating  Rooms 

One  (foldable  operating  table) 

14. 

Beds 

N/A 

15. 

Dental  Facilities 

N/A 

16. 

Self  Defense  Weapons 

N/A 

17. 

Offensive  Weapons 

Mk  96  Stabilized  Weapon  System,  (25mm 
Bushmaster  Cannon  &Mk  19  40mm  Grenade 
Launcher);  Mk  45  40mm  Grenade  Launcher 
System 

18. 

Radar  Type 

Assumed  to  include  equivalent  systems  as 
current  Mine  Warfare  surface  vessels  and 
Littoral  Combat  Ships  (LCS) 

19. 

Sonar 

20. 

Electronic  Warfare  /  Intel 

21. 

Communications 

HF/UHF/VHF 

22. 

Command/Flag  Space 

Two  Conference  Room,  two  Staff  Rooms 

Table  35.  Data  Sheet  for  JHSV  (after  [1]) 
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D.  VISBY  CLASS  CORVETTE 


S/N 

Parameters 

Description 

1. 

Displacement  (tonnes) 

600 

2. 

Draft  (Ft) 

7.5 

3. 

Endurance  (nm) 

2,300 

4. 

Speed  (knts) 

35 

5. 

Crew 

43  (total) 

6. 

Troops 

N/A 

7. 

Organic  Boats 

N/A 

8. 

Well  Deck  Capability 

N/A 

9. 

Cargo  Capacity  (ft^) 

N/A 

10. 

Vehicle  Space  (ft^) 

N/A 

11. 

Helo  Capable 

One 

12. 

Help  Spots 

One 

13. 

Organic  Aircraft 

N/A 

14. 

Operating  Rooms 

N/A 

15. 

Beds 

N/A 

16. 

Dental  Facilities 

N/A 

17. 

Self  Defense  Weapons 

Umkhonto  (Air  Defense  Missile) 

18. 

Offensive  Weapons 

Saab  Bofors  Dynamics  RBS  15  Mk2/MK3, 
Anti-Ship  Missile, 

Saab  40mm  Grenade  Launchers, 

Saab  Underwater  Systems  Tp  45  Torpedo, 
Saab  Underwater  Systems  Tp  45  Torpedo 
and  Bofors  57mm  70  SAK  MK3  GPMG 

19. 

Radar  Type 

SaabTech  CEROS  200  /  Fire  Control, 

Saab  Sea  Giraffe  AMB  /  Air  Search, 
Celsius  Tech  Pilot  I-band  Surface  Search  and 
CEROS  200  MK3  I/J-band  Fire  Control 
Radar 

20. 

Sonar 

Hydra  Multi-Sonar  Suite 

21. 

EW  /  Intel 

CS-3701  TRSS,  MASS  Decoy  System 

22. 

Communications 

CETRIS  C3 

23. 

Command/Flag  Space 

N/A 

126 


S/N 

Parameters 

Description 

24. 

Special  Features  (e.g.  Mission 
Modules) 

ASW,  AS,  MCM  mission  modules 

Table  36.  Data  Sheet  for  Visby  (after  [1]) 


E.  M-80  STILETTO 


S/N 

Parameters 

Description 

1. 

Displacement  (tonnes) 

45 

2. 

Draft  (ft) 

Three 

3. 

Endurance  (nm) 

500 

4. 

Speed  (knts) 

50 

5. 

Officers 

0 

6. 

Enlisted 

Three 

7. 

Troops 

Up  to  12 

8. 

Organic  Boats 

llmRHIB 

9. 

Well  Deck  Capability 

N/A 

10. 

Cargo  Capacity  (ft^) 

Internal  capacity  for  troops  and  equipment 

11. 

Vehicle  Space  (ft^) 

N/A 

12. 

Helo  Capable 

No 

13. 

Help  Spots 

N/A 

14. 

Organic  Aircraft 

Small  UAV  capable  landing  pad 

15. 

Operating  Rooms 

N/A 

16. 

Beds 

N/A 

17. 

Dental  Facilities 

N/A 

18. 

Self  Defense  Weapons 

Currently  none,  however,  space  provisions 
have  been  made  for  future  weapons 

19. 

Offensive  Weapons 

Currently  none,  however,  space  provisions 
have  been  made  for  future  weapons 

20. 

Radar 

Navigation  Radar 

21. 

Sonar 

N/A 

22. 

Electronic  Warfare  /  Intel 

Currently  none,  however,  space  provisions 
have  been  made  for  future  systems 
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S/N 

Parameters 

Description 

23. 

Communications 

Space  provisions  have  been  made  for  future 
systems 

24. 

Command/Flag  Space 

N/A 

Table  37.  Data  Sheet  for  M-80  Stiletto  (after  [1]) 


F.  CH-53K  SEA  STALLION 


S/N 

Parameters 

Description 

1. 

Max  Range  (nm  one  way) 

454 

2. 

Cruise  Airspeed  (kts) 

170 

3. 

Max  Airspeed  (kts) 

190 

4. 

Speed  with  external  load  (kts) 

100 

5. 

Inflight  Refueling 

Yes 

6. 

Max  Gross  Wt  (lbs) 

84,700 

7. 

Cargo  Lift  Capability  (lbs) 

36,000 

8. 

External  Lift  Capability  (lbs) 

36,000 

9. 

Normal  sling  lift  (lbs) 

27,000 

10. 

Number  of  passengers 

55 

11. 

Surface  Radar 

No 

12. 

Air  Radar 

No 

13. 

SAR/ISAR 

No 

14. 

Airborne  Mine  Counter-measures 

Yes 

15. 

Forward-Looking  Infrared  (FLIR) 

Yes 

16. 

Electronic  Warfare  /  Electronics 
Support  Measures 

Yes 

17. 

Sonobouys 

No 

18. 

Dipping  Sonar 

No 

Table  38.  Data  Sheet  for  CH-53K  Sea  Stallion  (after  [1]) 
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G.  SH-60S  SEAHAWK 


S/N 

Parameters 

Description 

1. 

Max  Range  (nm  one  way) 

200 

2. 

Cruise  Airspeed  (kts) 

147 

3. 

Max  Airspeed  (kts) 

180 

4. 

Speed  with  external  load  (kts) 

80 

5. 

Inflight  Refueling 

No 

6. 

Max  Gross  Wt  (lbs) 

22,000 

7. 

Cargo  Lift  Capability  (lbs) 

8,000 

8. 

External  Lift  Capability  (lbs) 

6,000 

9. 

Normal  sling  lift  (lbs) 

4,500 

10. 

Number  of  passengers 

12 

11. 

Surface  Radar 

No 

12. 

Air  Radar 

No 

13. 

SAR/ISAR 

No 

14. 

Airborne  Mine  Counter-measures 

Yes 

15. 

Forward-Looking  Infrared  (FLIR) 

Yes 

16. 

Electronic  Warfare  /  Electronics 
Support  Measures 

No 

17. 

Sonobouys 

No 

18. 

Dipping  Sonar 

No 

Table  39.  Data  Sheet  for  SH-60S  Seahawk  (after  [1]) 

H. 

RQ-8  FIRESCOUT  UAV 

S/N 

Parameters 

Description 

1. 

Length  (m) 

6.98 

2. 

Rotor  diameter  (m) 

8.38 

3. 

Height  (m) 

2.87 

4. 

Weight  (kg) 

max:  1200  ;  empty:  661 

5. 

Speed  (km/h) 

231 

129 


S/N 

Parameters 

Description 

6. 

Ceiling  (m) 

6,100 

7. 

Endurance  (hours) 

Five 

8. 

Propulsion 

Rolls-Royce/ Allison  250-C20W  turboshaft; 
310  kW  (420  shp) 

9. 

Length  (m) 

6.98 

Table  40.  Data  Sheet  for  RQ-8  Firescout  UAV  (after  [19]) 
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APPENDIX  B.  FINAL  AIRLIFT  MODEL  OUTPUT  FOR  CIVIL 
SUPPORT  MISSION  TEST  CASES 


The  following  is  the  output  generated  by  the  final  airlift  model  against  the  three 
Civil  Support  mission  scenario  test  cases.  Each  list  describes  the  sorties  flown  with 
details  on  the  aircraft  involved,  load  type  and  transferred  quantity,  event  timings  and  the 
remaining  load  left  after  that  sortie  assignment. 

A.  MODEL  OUTPUT  FROM  LOW  SEVERITY  SCENARIO  TEST  CASE 


Assign# 

Aircraft# 

Load 

Type# 

Transfer 

Qty 

Start 

Loading 

Time 

Start 

Sortie 

Time 

Reach 

Target 

Time 

Leave 

Target 

Time 

End 

Sortie 

Time 

Cargo 

Left 

Eqpt 

Left 

Passenger 

Left 

#1 

CH53#0 

1 

2 

0 

1 

4 

5 

6.76 

2232001 

4 

32 

#2 

SH60#0 

2 

12 

0 

5 

7.04 

12.04 

14.08 

2232001 

4 

20 

#3 

SH60#1 

2 

12 

0 

5 

7.04 

12.04 

14.08 

2232001 

4 

8 

#4 

CH53#0 

1 

2 

6.76 

7.76 

10.76 

11.76 

13.53 

2232001 

2 

8 

#5 

SH60#0 

2 

8 

14.08 

19.08 

21.12 

26.12 

28.16 

2232001 

2 

0 

#6 

SH60#1 

0 

4500 

14.08 

15.08 

18.83 

19.83 

21.87 

2227501 

2 

0 

#7 

CH53#0 

1 

2 

13.53 

14.53 

17.53 

18.53 

20.29 

2227501 

0 

0 

#8 

CH53#0 

0 

27000 

20.29 

21.29 

24.29 

25.29 

27.06 

2200501 

0 

0 

#9 

SH60#1 

0 

4500 

21.87 

22.87 

26.62 

27.62 

29.66 

2196001 

0 

0 

#10 

SH60#0 

0 

4500 

28.16 

29.16 

32.91 

33.91 

35.95 

2191501 

0 

0 

#11 

CH53#0 

0 

27000 

27.06 

28.06 

31.06 

32.06 

33.82 

2164501 

0 

0 

#12 

SH60#1 

0 

4500 

29.66 

30.66 

34.41 

35.41 

37.45 

2160001 

0 

0 

#13 

CH53#0 

0 

27000 

33.82 

34.82 

37.82 

38.82 

40.59 

2133001 

0 

0 

#14 

SH60#0 

0 

4500 

35.95 

36.95 

40.7 

41.7 

43.74 

2128501 

0 

0 

#15 

SH60#1 

0 

4500 

37.45 

38.45 

42.2 

43.2 

45.24 

2124001 

0 

0 

#16 

CH53#0 

0 

27000 

40.59 

41.59 

44.59 

45.59 

47.35 

2097001 

0 

0 

#17 

SH60#0 

0 

4500 

43.74 

44.74 

48.49 

49.49 

51.54 

2092501 

0 

0 

#18 

SH60#1 

0 

4500 

45.24 

46.24 

49.99 

50.99 

53.04 

2088001 

0 

0 

#19 

CH53#0 

0 

27000 

47.35 

48.35 

51.35 

52.35 

54.12 

2061001 

0 

0 

#20 

SH60#0 

0 

4500 

51.54 

52.54 

56.29 

57.29 

59.33 

2056501 

0 

0 

#21 

SH60#1 

0 

4500 

53.04 

54.04 

57.79 

58.79 

60.83 

2052001 

0 

0 

#22 

CH53#0 

0 

27000 

54.12 

55.12 

58.12 

59.12 

60.88 

2025001 

0 

0 

#23 

SH60#0 

0 

4500 

59.33 

60.33 

64.08 

65.08 

67.12 

2020501 

0 

0 

#24 

SH60#1 

0 

4500 

60.83 

61.83 

65.58 

66.58 

68.62 

2016001 

0 

0 

#25 

CH53#0 

0 

27000 

60.88 

61.88 

64.88 

65.88 

67.65 

1989001 

0 

0 

#26 

SH60#0 

0 

4500 

67.12 

68.12 

71.87 

72.87 

74.91 

1984501 

0 

0 

#27 

SH60#1 

0 

4500 

68.62 

69.62 

73.37 

74.37 

76.41 

1980001 

0 

0 

#28 

CH53#0 

0 

27000 

67.65 

68.65 

71.65 

72.65 

74.41 

1953001 

0 

0 

#29 

SH60#0 

0 

4500 

74.91 

75.91 

79.66 

80.66 

82.7 

1948501 

0 

0 

#30 

CH53#0 

0 

27000 

74.41 

75.41 

78.41 

79.41 

81.18 

1921501 

0 

0 

#31 

SH60#1 

0 

4500 

76.41 

77.41 

81.16 

82.16 

84.2 

1917001 

0 

0 

#32 

CH53#0 

0 

27000 

81.18 

82.18 

85.18 

86.18 

87.94 

1890001 

0 

0 

#33 

SH60#0 

0 

4500 

82.7 

83.7 

87.45 

88.45 

90.49 

1885501 

0 

0 

#34 

SH60#1 

0 

4500 

84.2 

85.2 

88.95 

89.95 

91.99 

1881001 

0 

0 

#35 

CH53#0 

0 

27000 

87.94 

88.94 

91.94 

92.94 

94.71 

1854001 

0 

0 
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Assign# 

Aircraft# 

Load 

Type# 

Transfer 

Qty 

Start 

Loading 

Time 

Start 

Sortie 

Time 

Reach 

Target 

Time 

Leave 

Target 

Time 

End 

Sortie 

Time 

Cargo 

Left 

Eqpt 

Left 

Passenger 

Left 

#36 

SH60#0 

0 

4500 

90.49 

91.49 

95.24 

96.24 

98.28 

1849501 

0 

0 

#37 

SH60#1 

0 

4500 

91.99 

92.99 

96.74 

97.74 

99.78 

1845001 

0 

0 

#38 

CH53#0 

0 

27000 

94.71 

95.71 

98.71 

99.71 

101.47 

1818001 

0 

0 

#39 

SH60#0 

0 

4500 

98.28 

99.28 

103.03 

104.03 

106.07 

1813501 

0 

0 

#40 

SH60#1 

0 

4500 

99.78 

100.78 

104.53 

105.53 

107.57 

1809001 

0 

0 

#41 

CH53#0 

0 

27000 

101.47 

102.47 

105.47 

106.47 

108.24 

1782001 

0 

0 

#42 

SH60#0 

0 

4500 

106.07 

107.07 

110.82 

111.82 

113.86 

1777501 

0 

0 

#43 

SH60#1 

0 

4500 

107.57 

108.57 

112.32 

113.32 

115.36 

1773001 

0 

0 

#44 

CH53#0 

0 

27000 

108.24 

109.24 

112.24 

113.24 

115 

1746001 

0 

0 

#45 

SH60#0 

0 

4500 

113.86 

114.86 

118.61 

119.61 

121.65 

1741501 

0 

0 

#46 

SH60#1 

0 

4500 

115.36 

116.36 

120.11 

121.11 

123.15 

1737001 

0 

0 

#47 

CH53#0 

0 

27000 

115 

116 

119 

120 

121.76 

1710001 

0 

0 

#48 

SH60#0 

0 

4500 

121.65 

122.65 

126.4 

127.4 

129.44 

1705501 

0 

0 

#49 

CH53#0 

0 

27000 

121.76 

122.76 

125.76 

126.76 

128.53 

1678501 

0 

0 

#50 

SH60#1 

0 

4500 

123.15 

124.15 

127.9 

128.9 

130.94 

1674001 

0 

0 

#51 

SH60#0 

0 

4500 

129.44 

130.44 

134.19 

135.19 

137.23 

1669501 

0 

0 

#52 

CH53#0 

0 

27000 

128.53 

129.53 

132.53 

133.53 

135.29 

1642501 

0 

0 

#53 

SH60#1 

0 

4500 

130.94 

131.94 

135.69 

136.69 

138.73 

1638001 

0 

0 

#54 

CH53#0 

0 

27000 

135.29 

136.29 

139.29 

140.29 

142.06 

1611001 

0 

0 

#55 

SH60#0 

0 

4500 

137.23 

138.23 

141.98 

142.98 

145.03 

1606501 

0 

0 

#56 

SH60#1 

0 

4500 

138.73 

139.73 

143.48 

144.48 

146.53 

1602001 

0 

0 

#57 

CH53#0 

0 

27000 

142.06 

143.06 

146.06 

147.06 

148.82 

1575001 

0 

0 

#58 

SH60#0 

0 

4500 

145.03 

146.03 

149.78 

150.78 

152.82 

1570501 

0 

0 

#59 

SH60#1 

0 

4500 

146.53 

147.53 

151.28 

152.28 

154.32 

1566001 

0 

0 

#60 

CH53#0 

0 

27000 

148.82 

149.82 

152.82 

153.82 

155.59 

1539001 

0 

0 

#61 

SH60#0 

0 

4500 

152.82 

153.82 

157.57 

158.57 

160.61 

1534501 

0 

0 

#62 

SH60#1 

0 

4500 

154.32 

155.32 

159.07 

160.07 

162.11 

1530001 

0 

0 

#63 

CH53#0 

0 

27000 

155.59 

156.59 

159.59 

160.59 

162.35 

1503001 

0 

0 

#64 

SH60#0 

0 

4500 

160.61 

161.61 

165.36 

166.36 

168.4 

1498501 

0 

0 

#65 

SH60#1 

0 

4500 

162.11 

163.11 

166.86 

167.86 

169.9 

1494001 

0 

0 

#66 

CH53#0 

0 

27000 

162.35 

163.35 

166.35 

167.35 

169.12 

1467001 

0 

0 

#67 

SH60#0 

0 

4500 

168.4 

169.4 

173.15 

174.15 

176.19 

1462501 

0 

0 

#68 

SH60#1 

0 

4500 

169.9 

170.9 

174.65 

175.65 

177.69 

1458001 

0 

0 

#69 

CH53#0 

0 

27000 

169.12 

170.12 

173.12 

174.12 

175.88 

1431001 

0 

0 

#70 

SH60#0 

0 

4500 

176.19 

177.19 

180.94 

181.94 

183.98 

1426501 

0 

0 

#71 

CH53#0 

0 

27000 

175.88 

176.88 

179.88 

180.88 

182.65 

1399501 

0 

0 

#72 

SH60#1 

0 

4500 

177.69 

178.69 

182.44 

183.44 

185.48 

1395001 

0 

0 

#73 

CH53#0 

0 

27000 

182.65 

183.65 

186.65 

187.65 

189.41 

1368001 

0 

0 

#74 

SH60#0 

0 

4500 

183.98 

184.98 

188.73 

189.73 

191.77 

1363501 

0 

0 

#75 

SH60#1 

0 

4500 

185.48 

186.48 

190.23 

191.23 

193.27 

1359001 

0 

0 

#76 

CH53#0 

0 

27000 

189.41 

190.41 

193.41 

194.41 

196.18 

1332001 

0 

0 

#77 

SH60#0 

0 

4500 

191.77 

192.77 

196.52 

197.52 

199.56 

1327501 

0 

0 

#78 

SH60#1 

0 

4500 

193.27 

194.27 

198.02 

199.02 

201.06 

1323001 

0 

0 

#79 

CH53#0 

0 

27000 

196.18 

197.18 

200.18 

201.18 

202.94 

1296001 

0 

0 

#80 

SH60#0 

0 

4500 

199.56 

200.56 

204.31 

205.31 

207.35 

1291501 

0 

0 

#81 

SH60#1 

0 

4500 

201.06 

202.06 

205.81 

206.81 

208.85 

1287001 

0 

0 

#82 

CH53#0 

0 

27000 

202.94 

203.94 

206.94 

207.94 

209.71 

1260001 

0 

0 

#83 

SH60#0 

0 

4500 

207.35 

208.35 

212.1 

213.1 

215.14 

1255501 

0 

0 

#84 

SH60#1 

0 

4500 

208.85 

209.85 

213.6 

214.6 

216.64 

1251001 

0 

0 

#85 

CH53#0 

0 

27000 

209.71 

210.71 

213.71 

214.71 

216.47 

1224001 

0 

0 
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Assign# 

Aircraft# 

Load 

Type# 

Transfer 

Qty 

Start 

Loading 

Time 

Start 

Sortie 

Time 

Reach 

Target 

Time 

Leave 

Target 

Time 

End 

Sortie 

Time 

Cargo 

Left 

Eqpt 

Left 

Passenger 

Left 

#86 

SH60#0 

0 

4500 

215.14 

216.14 

219.89 

220.89 

222.93 

1219501 

0 

0 

#87 

SH60#1 

0 

4500 

216.64 

217.64 

221.39 

222.39 

224.43 

1215001 

0 

0 

#88 

CH53#0 

0 

27000 

216.47 

217.47 

220.47 

221.47 

223.24 

1188001 

0 

0 

#89 

SH60#0 

0 

4500 

222.93 

223.93 

227.68 

228.68 

230.72 

1183501 

0 

0 

#90 

CH53#0 

0 

27000 

223.24 

224.24 

227.24 

228.24 

230 

1156501 

0 

0 

#91 

SH60#1 

0 

4500 

224.43 

225.43 

229.18 

230.18 

232.22 

1152001 

0 

0 

#92 

SH60#0 

0 

4500 

230.72 

231.72 

235.47 

236.47 

238.52 

1147501 

0 

0 

#93 

CH53#0 

0 

27000 

230 

231 

234 

235 

236.76 

1120501 

0 

0 

#94 

SH60#1 

0 

4500 

232.22 

233.22 

236.97 

237.97 

240.02 

1116001 

0 

0 

#95 

CH53#0 

0 

27000 

236.76 

237.76 

240.76 

241.76 

243.53 

1089001 

0 

0 

#96 

SH60#0 

0 

4500 

238.52 

239.52 

243.27 

244.27 

246.31 

1084501 

0 

0 

#97 

SH60#1 

0 

4500 

240.02 

241.02 

244.77 

245.77 

247.81 

1080001 

0 

0 

#98 

CH53#0 

0 

27000 

243.53 

244.53 

247.53 

248.53 

250.29 

1053001 

0 

0 

#99 

SH60#0 

0 

4500 

246.31 

247.31 

251.06 

252.06 

254.1 

1048501 

0 

0 

#100 

SH60#1 

0 

4500 

247.81 

248.81 

252.56 

253.56 

255.6 

1044001 

0 

0 

#101 

CH53#0 

0 

27000 

250.29 

251.29 

254.29 

255.29 

257.06 

1017001 

0 

0 

#102 

SH60#0 

0 

4500 

254.1 

255.1 

258.85 

259.85 

261.89 

1012501 

0 

0 

#103 

SH60#1 

0 

4500 

255.6 

256.6 

260.35 

261.35 

263.39 

1008001 

0 

0 

#104 

CH53#0 

0 

27000 

257.06 

258.06 

261.06 

262.06 

263.82 

981001 

0 

0 

#105 

SH60#0 

0 

4500 

261.89 

262.89 

266.64 

267.64 

269.68 

976501 

0 

0 

#106 

SH60#1 

0 

4500 

263.39 

264.39 

268.14 

269.14 

271.18 

972001 

0 

0 

#107 

CH53#0 

0 

27000 

263.82 

264.82 

267.82 

268.82 

270.59 

945001 

0 

0 

#108 

SH60#0 

0 

4500 

269.68 

270.68 

274.43 

275.43 

277.47 

940501 

0 

0 

#109 

SH60#1 

0 

4500 

271.18 

272.18 

275.93 

276.93 

278.97 

936001 

0 

0 

#110 

CH53#0 

0 

27000 

270.59 

271.59 

274.59 

275.59 

277.35 

909001 

0 

0 

#111 

SH60#0 

0 

4500 

277.47 

278.47 

282.22 

283.22 

285.26 

904501 

0 

0 

#112 

CH53#0 

0 

27000 

277.35 

278.35 

281.35 

282.35 

284.12 

877501 

0 

0 

#113 

SH60#1 

0 

4500 

278.97 

279.97 

283.72 

284.72 

286.76 

873001 

0 

0 

#114 

CH53#0 

0 

27000 

284.12 

285.12 

288.12 

289.12 

290.88 

846001 

0 

0 

#115 

SH60#0 

0 

4500 

285.26 

286.26 

290.01 

291.01 

293.05 

841501 

0 

0 

#116 

SH60#1 

0 

4500 

286.76 

287.76 

291.51 

292.51 

294.55 

837001 

0 

0 

#117 

CH53#0 

0 

27000 

290.88 

291.88 

294.88 

295.88 

297.65 

810001 

0 

0 

#118 

SH60#0 

0 

4500 

293.05 

294.05 

297.8 

298.8 

300.84 

805501 

0 

0 

#119 

SH60#1 

0 

4500 

294.55 

295.55 

299.3 

300.3 

302.34 

801001 

0 

0 

#120 

CH53#0 

0 

27000 

297.65 

298.65 

301.65 

302.65 

304.41 

774001 

0 

0 

#121 

SH60#0 

0 

4500 

300.84 

301.84 

305.59 

306.59 

308.63 

769501 

0 

0 

#122 

SH60#1 

0 

4500 

302.34 

303.34 

307.09 

308.09 

310.13 

765001 

0 

0 

#123 

CH53#0 

0 

27000 

304.41 

305.41 

308.41 

309.41 

311.18 

738001 

0 

0 

#124 

SH60#0 

0 

4500 

308.63 

309.63 

313.38 

314.38 

316.42 

733501 

0 

0 

#125 

SH60#1 

0 

4500 

310.13 

311.13 

314.88 

315.88 

317.92 

729001 

0 

0 

#126 

CH53#0 

0 

27000 

311.18 

312.18 

315.18 

316.18 

317.94 

702001 

0 

0 

#127 

SH60#0 

0 

4500 

316.42 

317.42 

321.17 

322.17 

324.21 

697501 

0 

0 

#128 

SH60#1 

0 

4500 

317.92 

318.92 

322.67 

323.67 

325.71 

693001 

0 

0 

#129 

CH53#0 

0 

27000 

317.94 

318.94 

321.94 

322.94 

324.71 

666001 

0 

0 

#130 

SH60#0 

0 

4500 

324.21 

325.21 

328.96 

329.96 

332.01 

661501 

0 

0 

#131 

SH60#1 

0 

4500 

325.71 

326.71 

330.46 

331.46 

333.51 

657001 

0 

0 

#132 

CH53#0 

0 

27000 

324.71 

325.71 

328.71 

329.71 

331.47 

630001 

0 

0 

#133 

SH60#0 

0 

4500 

332.01 

333.01 

336.76 

337.76 

339.8 

625501 

0 

0 

#134 

CH53#0 

0 

27000 

331.47 

332.47 

335.47 

336.47 

338.24 

598501 

0 

0 

#135 

SH60#1 

0 

4500 

333.51 

334.51 

338.26 

339.26 

341.3 

594001 

0 

0 
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Assign# 

Aircraft# 

Load 

Type# 

Transfer 

Qty 

Start 

Loading 

Time 

Start 

Sortie 

Time 

Reach 

Target 

Time 

Leave 

Target 

Time 

End 

Sortie 

Time 

Cargo 

Left 

Eqpt 

Left 

Passenger 

Left 

#136 

CH53#0 

0 

27000 

338.24 

339.24 

342.24 

343.24 

345 

567001 

0 

0 

#137 

SH60#0 

0 

4500 

339.8 

340.8 

344.55 

345.55 

347.59 

562501 

0 

0 

#138 

SH60#1 

0 

4500 

341.3 

342.3 

346.05 

347.05 

349.09 

558001 

0 

0 

#139 

CH53#0 

0 

27000 

345 

346 

349 

350 

351.76 

531001 

0 

0 

#140 

SH60#0 

0 

4500 

347.59 

348.59 

352.34 

353.34 

355.38 

526501 

0 

0 

#141 

SH60#1 

0 

4500 

349.09 

350.09 

353.84 

354.84 

356.88 

522001 

0 

0 

#142 

CH53#0 

0 

27000 

351.76 

352.76 

355.76 

356.76 

358.53 

495001 

0 

0 

#143 

SH60#0 

0 

4500 

355.38 

356.38 

360.13 

361.13 

363.17 

490501 

0 

0 

#144 

SH60#1 

0 

4500 

356.88 

357.88 

361.63 

362.63 

364.67 

486001 

0 

0 

#145 

CH53#0 

0 

27000 

358.53 

359.53 

362.53 

363.53 

365.29 

459001 

0 

0 

#146 

SH60#0 

0 

4500 

363.17 

364.17 

367.92 

368.92 

370.96 

454501 

0 

0 

#147 

SH60#1 

0 

4500 

364.67 

365.67 

369.42 

370.42 

372.46 

450001 

0 

0 

#148 

CH53#0 

0 

27000 

365.29 

366.29 

369.29 

370.29 

372.06 

423001 

0 

0 

#149 

SH60#0 

0 

4500 

370.96 

371.96 

375.71 

376.71 

378.75 

418501 

0 

0 

#150 

SH60#1 

0 

4500 

372.46 

373.46 

377.21 

378.21 

380.25 

414001 

0 

0 

#151 

CH53#0 

0 

27000 

372.06 

373.06 

376.06 

377.06 

378.82 

387001 

0 

0 

#152 

SH60#0 

0 

4500 

378.75 

379.75 

383.5 

384.5 

386.54 

382501 

0 

0 

#153 

CH53#0 

0 

27000 

378.82 

379.82 

382.82 

383.82 

385.59 

355501 

0 

0 

#154 

SH60#1 

0 

4500 

380.25 

381.25 

385 

386 

388.04 

351001 

0 

0 

#155 

SH60#0 

0 

4500 

386.54 

387.54 

391.29 

392.29 

394.33 

346501 

0 

0 

#156 

CH53#0 

0 

27000 

385.59 

386.59 

389.59 

390.59 

392.35 

319501 

0 

0 

#157 

SH60#1 

0 

4500 

388.04 

389.04 

392.79 

393.79 

395.83 

315001 

0 

0 

#158 

CH53#0 

0 

27000 

392.35 

393.35 

396.35 

397.35 

399.12 

288001 

0 

0 

#159 

SH60#0 

0 

4500 

394.33 

395.33 

399.08 

400.08 

402.12 

283501 

0 

0 

#160 

SH60#1 

0 

4500 

395.83 

396.83 

400.58 

401.58 

403.62 

279001 

0 

0 

#161 

CH53#0 

0 

27000 

399.12 

400.12 

403.12 

404.12 

405.88 

252001 

0 

0 

#162 

SH60#0 

0 

4500 

402.12 

403.12 

406.87 

407.87 

409.91 

247501 

0 

0 

#163 

SH60#1 

0 

4500 

403.62 

404.62 

408.37 

409.37 

411.41 

243001 

0 

0 

#164 

CH53#0 

0 

27000 

405.88 

406.88 

409.88 

410.88 

412.65 

216001 

0 

0 

#165 

SH60#0 

0 

4500 

409.91 

410.91 

414.66 

415.66 

417.7 

211501 

0 

0 

#166 

SH60#1 

0 

4500 

411.41 

412.41 

416.16 

417.16 

419.2 

207001 

0 

0 

#167 

CH53#0 

0 

27000 

412.65 

413.65 

416.65 

417.65 

419.41 

180001 

0 

0 

#168 

SH60#0 

0 

4500 

417.7 

418.7 

422.45 

423.45 

425.49 

175501 

0 

0 

#169 

SH60#1 

0 

4500 

419.2 

420.2 

423.95 

424.95 

426.99 

171001 

0 

0 

#170 

CH53#0 

0 

27000 

419.41 

420.41 

423.41 

424.41 

426.18 

144001 

0 

0 

#171 

SH60#0 

0 

4500 

425.49 

426.49 

430.24 

431.24 

433.29 

139501 

0 

0 

#172 

SH60#1 

0 

4500 

426.99 

427.99 

431.74 

432.74 

434.79 

135001 

0 

0 

#173 

CH53#0 

0 

27000 

426.18 

427.18 

430.18 

431.18 

432.94 

108001 

0 

0 

#174 

SH60#0 

0 

4500 

433.29 

434.29 

438.04 

439.04 

441.08 

103501 

0 

0 

#175 

CH53#0 

0 

27000 

432.94 

433.94 

436.94 

437.94 

439.71 

76501 

0 

0 

#176 

SH60#1 

0 

4500 

434.79 

435.79 

439.54 

440.54 

442.58 

72001 

0 

0 

#177 

CH53#0 

0 

27000 

439.71 

440.71 

443.71 

444.71 

446.47 

45001 

0 

0 

#178 

SH60#0 

0 

4500 

441.08 

442.08 

445.83 

446.83 

448.87 

40501 

0 

0 

#179 

SH60#1 

0 

4500 

442.58 

443.58 

447.33 

448.33 

450.37 

36001 

0 

0 

#180 

CH53#0 

0 

27000 

446.47 

447.47 

450.47 

451.47 

453.24 

9001 

0 

0 

#181 

SH60#0 

0 

4500 

448.87 

449.87 

453.62 

454.62 

456.66 

4501 

0 

0 

#182 

SH60#1 

0 

4500 

450.37 

451.37 

455.12 

456.12 

458.16 

1 

0 

0 

#183 

CH53#0 

0 

1 

453.24 

454.24 

457.24 

458.24 

460 

0 

0 

0 

Table  41.  Final  Airlift  Model  Output  for  Low  Severity  Scenario  Test  Case 
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B. 


MODEL  OUTPUT  FROM  MEAN  SEVERITY  SCENARIO  TEST  CASE 


Assign# 

Aircraft# 

Load 

Type# 

Transfer 

Qty 

Start 

Loading 

Time 

Start 

Sortie 

Time 

Reach 

Target 

Time 

Leave 

Target 

Time 

End 

Sortie 

Time 

Cargo 

Left 

Eqpt 

Left 

Passenger 

Left 

#1 

CH53#0 

1 

2 

0 

1 

19 

20 

30.59 

729001 

9 

72 

#2 

CH53#1 

1 

2 

0 

1 

19 

20 

30.59 

729001 

7 

72 

#3 

SH60#0 

2 

12 

0 

5 

17.26 

22.26 

34.51 

729001 

7 

60 

#4 

SH60#1 

2 

12 

0 

5 

17.26 

22.26 

34.51 

729001 

7 

48 

#5 

CH53#0 

1 

2 

30.59 

31.59 

49.59 

50.59 

61.18 

729001 

5 

48 

#6 

CH53#1 

1 

2 

30.59 

31.59 

49.59 

50.59 

61.18 

729001 

3 

48 

#7 

SH60#0 

2 

12 

34.51 

39.51 

51.77 

56.77 

69.03 

729001 

3 

36 

#8 

SH60#1 

2 

12 

34.51 

39.51 

51.77 

56.77 

69.03 

729001 

3 

24 

#9 

CH53#0 

1 

2 

61.18 

62.18 

80.18 

81.18 

91.76 

729001 

1 

24 

#10 

CH53#1 

1 

1 

61.18 

62.18 

80.18 

81.18 

91.76 

729001 

0 

24 

#11 

SH60#0 

2 

12 

69.03 

74.03 

86.29 

91.29 

103.54 

729001 

0 

12 

#12 

SH60#1 

2 

12 

69.03 

74.03 

86.29 

91.29 

103.54 

729001 

0 

0 

#13 

CH53#0 

0 

27000 

91.76 

92.76 

110.76 

111.76 

122.35 

702001 

0 

0 

#14 

CH53#1 

0 

27000 

91.76 

92.76 

110.76 

111.76 

122.35 

675001 

0 

0 

#15 

SH60#0 

0 

4500 

103.54 

104.54 

127.07 

128.07 

140.32 

670501 

0 

0 

#16 

SH60#1 

0 

4500 

103.54 

104.54 

127.07 

128.07 

140.32 

666001 

0 

0 

#17 

CH53#0 

0 

27000 

122.35 

123.35 

141.35 

142.35 

152.94 

639001 

0 

0 

#18 

CH53#1 

0 

27000 

122.35 

123.35 

141.35 

142.35 

152.94 

612001 

0 

0 

#19 

SH60#0 

0 

4500 

140.32 

141.32 

163.84 

164.84 

177.1 

607501 

0 

0 

#20 

SH60#1 

0 

4500 

140.32 

141.32 

163.84 

164.84 

177.1 

603001 

0 

0 

#21 

CH53#0 

0 

27000 

152.94 

153.94 

171.94 

172.94 

183.53 

576001 

0 

0 

#22 

CH53#1 

0 

27000 

152.94 

153.94 

171.94 

172.94 

183.53 

549001 

0 

0 

#23 

SH60#0 

0 

4500 

177.1 

178.1 

200.62 

201.62 

213.88 

544501 

0 

0 

#24 

SH60#1 

0 

4500 

177.1 

178.1 

200.62 

201.62 

213.88 

540001 

0 

0 

#25 

CH53#0 

0 

27000 

183.53 

184.53 

202.53 

203.53 

214.12 

513001 

0 

0 

#26 

CH53#1 

0 

27000 

183.53 

184.53 

202.53 

203.53 

214.12 

486001 

0 

0 

#27 

SH60#0 

0 

4500 

213.88 

214.88 

237.4 

238.4 

250.66 

481501 

0 

0 

#28 

SH60#1 

0 

4500 

213.88 

214.88 

237.4 

238.4 

250.66 

477001 

0 

0 

#29 

CH53#0 

0 

27000 

214.12 

215.12 

233.12 

234.12 

244.71 

450001 

0 

0 

#30 

CH53#1 

0 

27000 

214.12 

215.12 

233.12 

234.12 

244.71 

423001 

0 

0 

#31 

SH60#0 

0 

4500 

250.66 

251.66 

274.18 

275.18 

287.44 

418501 

0 

0 

#32 

SH60#1 

0 

4500 

250.66 

251.66 

274.18 

275.18 

287.44 

414001 

0 

0 

#33 

CH53#0 

0 

27000 

244.71 

245.71 

263.71 

264.71 

275.29 

387001 

0 

0 

#34 

CH53#1 

0 

27000 

244.71 

245.71 

263.71 

264.71 

275.29 

360001 

0 

0 

#35 

CH53#0 

0 

27000 

275.29 

276.29 

294.29 

295.29 

305.88 

333001 

0 

0 

#36 

CH53#1 

0 

27000 

275.29 

276.29 

294.29 

295.29 

305.88 

306001 

0 

0 

#37 

SH60#0 

0 

4500 

287.44 

288.44 

310.96 

311.96 

324.22 

301501 

0 

0 

#38 

SH60#1 

0 

4500 

287.44 

288.44 

310.96 

311.96 

324.22 

297001 

0 

0 

#39 

CH53#0 

0 

27000 

305.88 

306.88 

324.88 

325.88 

336.47 

270001 

0 

0 

#40 

CH53#1 

0 

27000 

305.88 

306.88 

324.88 

325.88 

336.47 

243001 

0 

0 

#41 

SH60#0 

0 

4500 

324.22 

325.22 

347.74 

348.74 

361 

238501 

0 

0 

#42 

SH60#1 

0 

4500 

324.22 

325.22 

347.74 

348.74 

361 

234001 

0 

0 

#43 

CH53#0 

0 

27000 

336.47 

337.47 

355.47 

356.47 

367.06 

207001 

0 

0 

#44 

CH53#1 

0 

27000 

336.47 

337.47 

355.47 

356.47 

367.06 

180001 

0 

0 

#45 

SH60#0 

0 

4500 

361 

362 

384.52 

385.52 

397.78 

175501 

0 

0 

#46 

SH60#1 

0 

4500 

361 

362 

384.52 

385.52 

397.78 

171001 

0 

0 

#47 

CH53#0 

0 

27000 

367.06 

368.06 

386.06 

387.06 

397.65 

144001 

0 

0 

#48 

CH53#1 

0 

27000 

367.06 

368.06 

386.06 

387.06 

397.65 

117001 

0 

0 
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Assign# 

Aircraft# 

Load 

Type# 

Transfer 

Qty 

Start 

Loading 

Time 

Start 

Sortie 

Time 

Reach 

Target 

Time 

Leave 

Target 

Time 

End 

Sortie 

Time 

Cargo 

Left 

Eqpt 

Left 

Passenger 

Left 

#49 

SH60#0 

0 

4500 

397.78 

398.78 

421.3 

422.3 

434.56 

112501 

0 

0 

#50 

SH60#1 

0 

4500 

397.78 

398.78 

421.3 

422.3 

434.56 

108001 

0 

0 

#51 

CH53#0 

0 

27000 

397.65 

398.65 

416.65 

417.65 

428.24 

81001 

0 

0 

#52 

CH53#1 

0 

27000 

397.65 

398.65 

416.65 

417.65 

428.24 

54001 

0 

0 

#53 

CH53#0 

0 

27000 

428.24 

429.24 

447.24 

448.24 

458.82 

27001 

0 

0 

#54 

CH53#1 

0 

27000 

428.24 

429.24 

447.24 

448.24 

458.82 

1 

0 

0 

#55 

SH60#0 

0 

1 

434.56 

435.56 

458.08 

459.08 

471.34 

0 

0 

0 

Table  42.  Final  Airlift  Model  Output  for  Mean  Severity  Scenario  Test  Case 


C.  MODEL  OUTPUT  FROM  HIGH  SEVERITY  SCENARIO  TEST  CASE 


Assign# 

Aircraft# 

Load 

Type# 

Transfer 

Qty 

Start 

Loading 

Time 

Start 

Sortie 

Time 

Reach 

Target 

Time 

Leave 

Target 

Time 

End 

Sortie 

Time 

Cargo 

Left 

Eqpt 

Left 

Passenger 

Left 

#1 

CH53#0 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

14 

99 

#2 

CH53#1 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

12 

99 

#3 

CH53#2 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

10 

99 

#4 

CH53#3 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

8 

99 

#5 

CH53#4 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

6 

99 

#6 

CH53#5 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

4 

99 

#7 

CH53#6 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

2 

99 

#8 

SH60#0 

2 

12 

0 

5 

27.45 

32.45 

54.9 

1318501 

2 

87 

#9 

SH60#1 

2 

12 

0 

5 

27.45 

32.45 

54.9 

1318501 

2 

75 

#10 

CH53#0 

1 

2 

54.41 

55.41 

88.41 

89.41 

108.82 

1318501 

0 

75 

#11 

CH53#1 

0 

27000 

54.41 

55.41 

88.41 

89.41 

108.82 

1291501 

0 

75 

#12 

CH53#2 

0 

27000 

54.41 

55.41 

88.41 

89.41 

108.82 

1264501 

0 

75 

#13 

CH53#3 

0 

27000 

54.41 

55.41 

88.41 

89.41 

108.82 

1237501 

0 

75 

#14 

CH53#4 

0 

27000 

54.41 

55.41 

88.41 

89.41 

108.82 

1210501 

0 

75 

#15 

CH53#5 

0 

27000 

54.41 

55.41 

88.41 

89.41 

108.82 

1183501 

0 

75 

#16 

CH53#6 

0 

27000 

54.41 

55.41 

88.41 

89.41 

108.82 

1156501 

0 

75 

#17 

SH60#0 

2 

12 

54.9 

59.9 

82.35 

87.35 

109.8 

1156501 

0 

63 

#18 

SH60#1 

2 

12 

54.9 

59.9 

82.35 

87.35 

109.8 

1156501 

0 

51 

#19 

CH53#0 

0 

27000 

108.82 

109.82 

142.82 

143.82 

163.24 

1129501 

0 

51 

#20 

CH53#1 

0 

27000 

108.82 

109.82 

142.82 

143.82 

163.24 

1102501 

0 

51 

#21 

CH53#2 

0 

27000 

108.82 

109.82 

142.82 

143.82 

163.24 

1075501 

0 

51 

#22 

CH53#3 

0 

27000 

108.82 

109.82 

142.82 

143.82 

163.24 

1048501 

0 

51 

#23 

CH53#4 

0 

27000 

108.82 

109.82 

142.82 

143.82 

163.24 

1021501 

0 

51 

#24 

CH53#5 

0 

27000 

108.82 

109.82 

142.82 

143.82 

163.24 

994501 

0 

51 

#25 

CH53#6 

0 

27000 

108.82 

109.82 

142.82 

143.82 

163.24 

967501 

0 

51 

#26 

SH60#0 

2 

12 

109.8 

114.8 

137.24 

142.24 

164.69 

967501 

0 

39 

#27 

SH60#1 

2 

12 

109.8 

114.8 

137.24 

142.24 

164.69 

967501 

0 

27 

#28 

CH53#0 

0 

27000 

163.24 

164.24 

197.24 

198.24 

217.65 

940501 

0 

27 

#29 

CH53#1 

0 

27000 

163.24 

164.24 

197.24 

198.24 

217.65 

913501 

0 

27 

#30 

CH53#2 

0 

27000 

163.24 

164.24 

197.24 

198.24 

217.65 

886501 

0 

27 

#31 

CH53#3 

0 

27000 

163.24 

164.24 

197.24 

198.24 

217.65 

859501 

0 

27 

#32 

CH53#4 

0 

27000 

163.24 

164.24 

197.24 

198.24 

217.65 

832501 

0 

27 

#33 

CH53#5 

0 

27000 

163.24 

164.24 

197.24 

198.24 

217.65 

805501 

0 

27 

#34 

CH53#6 

0 

27000 

163.24 

164.24 

197.24 

198.24 

217.65 

778501 

0 

27 

#35 

SH60#0 

2 

12 

164.69 

169.69 

192.14 

197.14 

219.59 

778501 

0 

15 
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Assign# 

Aircraft# 

Load 

Type# 

Transfer 

Qty 

Start 

Loading 

Time 

Start 

Sortie 

Time 

Reach 

Target 

Time 

Leave 

Target 

Time 

End 

Sortie 

Time 

Cargo 

Left 

Eqpt 

Left 

Passenger 

Left 

#36 

SH60#1 

2 

12 

164.69 

169.69 

192.14 

197.14 

219.59 

778501 

0 

3 

#37 

CH53#0 

0 

27000 

217.65 

218.65 

251.65 

252.65 

272.06 

751501 

0 

3 

#38 

CH53#1 

0 

27000 

217.65 

218.65 

251.65 

252.65 

272.06 

724501 

0 

3 

#39 

CH53#2 

0 

27000 

217.65 

218.65 

251.65 

252.65 

272.06 

697501 

0 

3 

#40 

CH53#3 

0 

27000 

217.65 

218.65 

251.65 

252.65 

272.06 

670501 

0 

3 

#41 

CH53#4 

0 

27000 

217.65 

218.65 

251.65 

252.65 

272.06 

643501 

0 

3 

#42 

CH53#5 

0 

27000 

217.65 

218.65 

251.65 

252.65 

272.06 

616501 

0 

3 

#43 

CH53#6 

0 

27000 

217.65 

218.65 

251.65 

252.65 

272.06 

589501 

0 

3 

#44 

SH60#0 

2 

3 

219.59 

224.59 

247.04 

252.04 

274.49 

589501 

0 

0 

#45 

SH60#1 

0 

4500 

219.59 

220.59 

261.84 

262.84 

285.29 

585001 

0 

0 

#46 

CH53#0 

0 

27000 

272.06 

273.06 

306.06 

307.06 

326.47 

558001 

0 

0 

#47 

CH53#1 

0 

27000 

272.06 

273.06 

306.06 

307.06 

326.47 

531001 

0 

0 

#48 

CH53#2 

0 

27000 

272.06 

273.06 

306.06 

307.06 

326.47 

504001 

0 

0 

#49 

CH53#3 

0 

27000 

272.06 

273.06 

306.06 

307.06 

326.47 

477001 

0 

0 

#50 

CH53#4 

0 

27000 

272.06 

273.06 

306.06 

307.06 

326.47 

450001 

0 

0 

#51 

CH53#5 

0 

27000 

272.06 

273.06 

306.06 

307.06 

326.47 

423001 

0 

0 

#52 

CH53#6 

0 

27000 

272.06 

273.06 

306.06 

307.06 

326.47 

396001 

0 

0 

#53 

SH60#1 

0 

4500 

285.29 

286.29 

327.54 

328.54 

350.99 

391501 

0 

0 

#54 

SH60#0 

0 

4500 

274.49 

275.49 

316.74 

317.74 

340.19 

387001 

0 

0 

#55 

CH53#0 

0 

27000 

326.47 

327.47 

360.47 

361.47 

380.88 

360001 

0 

0 

#56 

CH53#1 

0 

27000 

326.47 

327.47 

360.47 

361.47 

380.88 

333001 

0 

0 

#57 

CH53#2 

0 

27000 

326.47 

327.47 

360.47 

361.47 

380.88 

306001 

0 

0 

#58 

CH53#3 

0 

27000 

326.47 

327.47 

360.47 

361.47 

380.88 

279001 

0 

0 

#59 

CH53#4 

0 

27000 

326.47 

327.47 

360.47 

361.47 

380.88 

252001 

0 

0 

#60 

CH53#5 

0 

27000 

326.47 

327.47 

360.47 

361.47 

380.88 

225001 

0 

0 

#61 

CH53#6 

0 

27000 

326.47 

327.47 

360.47 

361.47 

380.88 

198001 

0 

0 

#62 

SH60#0 

0 

4500 

340.19 

341.19 

382.44 

383.44 

405.89 

193501 

0 

0 

#63 

SH60#1 

0 

4500 

350.99 

351.99 

393.24 

394.24 

416.69 

189001 

0 

0 

#64 

CH53#0 

0 

27000 

380.88 

381.88 

414.88 

415.88 

435.29 

162001 

0 

0 

#65 

CH53#1 

0 

27000 

380.88 

381.88 

414.88 

415.88 

435.29 

135001 

0 

0 

#66 

CH53#2 

0 

27000 

380.88 

381.88 

414.88 

415.88 

435.29 

108001 

0 

0 

#67 

CH53#3 

0 

27000 

380.88 

381.88 

414.88 

415.88 

435.29 

81001 

0 

0 

#68 

CH53#4 

0 

27000 

380.88 

381.88 

414.88 

415.88 

435.29 

54001 

0 

0 

#69 

CH53#5 

0 

27000 

380.88 

381.88 

414.88 

415.88 

435.29 

27001 

0 

0 

#70 

CH53#6 

0 

27000 

380.88 

381.88 

414.88 

415.88 

435.29 

1 

0 

0 

#71 

SH60#0 

0 

1 

405.89 

406.89 

448.14 

449.14 

471.59 

0 

0 

0 

Table  43.  Final  Airlift  Model  Output  for  High  Severity  Scenario  Test  Case 
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APPENDIX  C.  INPUT  PARAMETERS  FOR  EXPERIMENT  #I 


Table  44.  Input  Parameters  for  Experiment  #1 
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Table  45.  Input  Parameters  for  Experiment  #1  (Continued) 
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Table  46.  Input  Parameters  for  Experiment  #1  (Continued) 
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Table  47.  Input  Parameters  for  Experiment  #1  (Continued) 
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Table  48.  Input  Parameters  for  Experiment  #1  (Continued) 
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Table  49.  Input  Parameters  for  Experiment  #1  (Continued) 
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